This is a clip from a conversation with Bjarne Stroustrup from Nov 2019. New full episodes are released once or twice a week and 1-2 new clips or a new non-podcast video is released on all other days. If you enjoy it, subscribe, comment, and share. You can watch the full conversation here: ruclips.net/video/uTxRF5ag27A/видео.html (more links below) Podcast full episodes playlist: ruclips.net/p/PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4 Podcasts clips playlist: ruclips.net/p/PLrAXtmErZgOeciFP3CBCIEElOJeitOr41 Podcast website: lexfridman.com/ai Podcast on Apple Podcasts (iTunes): apple.co/2lwqZIr Podcast on Spotify: spoti.fi/2nEwCF8 Podcast RSS: lexfridman.com/category/ai/feed/
It brings up an interesting notion. A notion that applies to computer science in the most fundamental way. The notion of TIME. Anyone "could" do anything. A baby "could" eventually write their own linker. Or perform brain surgery, etc. It's just a question of time and efficiency. He "could" have done it, but would it be worth his time?
@@ollydix The language, as a whole, is so expressive that it tends to introduce more problems(via buggy code) than provisions for solutions. C++ could be one of the most productive programming languages while being the most troublesome at the same time. James Gosling and Bjarne Stroustrup both agreed on that finding when Java started gaining appeal in the mid to late 1990's.
I was hoping this question would be about the significant differences in machine code/assembly (size and executable speed) between these different compilers - for the SAME destination CPU.
I honestly don't think that would be a productive conversation. Which architecture(s) do we choose to talk about? What program(s) are we compiling for that architecture? Broadly speaking, the major compiler implementations for C++ are the same: they only differ (for the user) when you start comparing specific examples. And when you start getting too specific, you risk your facts getting out of date. All of the implementations are still being worked on.
I noticed a lot of developers have that demeanor I think it's just from sitting too long at a time everyday. He seems pretty cool tho as unlike other developers, he has a LOT of hobbies 👌
Excellent interview thank you. Two important facts to do for a responsibly outcome efficiency and reliability. I agree 100% to know the basics in whatever you are going to do. Gave you the micro knowledge of how things work.
Love your show. I'm not real familiar with some of the vocabulary and I think the words such as front-end, back-end, compiler, etc... are overloaded just enough that it's difficult to find a reasonable explanation on Google. Can you help me understand what front-end / back-end means when talking about compilers? My intuition is suggesting that a compiler is the part of the tool-chain that creates the actual machine code - or possible assembly. I'm not sure if this is synonymous with back-end. And front-end sounds like it's just a parser that streams an AST to any number of backends. So a C++ frontend could write to a C back-end ? Sort of confusing - but I'm quite curious.
front end parses the syntax and generates some sort of intermediate, platform independent representation. Backend takes that IR, and generates native machine code for that architecture/OS and performs optimizations
I think the last question was misinterpreted ;) Lex was talking about a clean slate C++ language, while Bjarne assumed they were still talking about compilers.
2:50 "I happen to dislike monocultures." The Rust foundation can afford to do whatever the hell they want because Rust only has one compiler. I think it would be very good if GCC manages to implement a Rust frontend. But there has to be a standard first.
I'm pretty sure that rather sooner than later someone will write a new C++ compiler. And I'm 100% sure that it will be done in Rust. They will claim that it will be supposedly better to do it this way.
@Vishwesh Rajurkar Uh. No it isnt. Visual C++ is the most behind on the standard and is non-conforming. It also produces extremely slow machine code and has limited optimization
mingw64 is GCC. LLVM is a backend (which is used by clang), not a frontend. icc, if I remember correctly, use edg as its frontend. And, correct me if I'm wrong, but I don't think zig compiler compiles c++ (it does compile c, though)
Intel's compiler is a back-end designed to produce well optimized machine code for Intel's hardware specifically, similarly to the "embedded" back-ends Bjarne mentions.
Zig CC is built on top of the clang libraries. Mingw64 is a GCC port. LLVM is essentially a set of libraries from which you can build a compiler from and is closely tied with clang which is a set of libraries under the umbrella of the LLVM project for parsing and otherwise manipulating C-family languages. ICC used to be built on EDG but I think they've been transitioning to Clang recently. Essentially, C++ is a language that is not designed to be easy to parse. Its not just a case of building a simple EBNF recursive descent parser. You sometimes have to finish parsing an entire statement before you know what the first few tokens refer to (look up the "most vexing parse" as an example). Because of that it's not worth considering writing your own front end unless you have a really good reason and a lot of resource. EDG is a good commercial option. GCC's aim is to provide a free software implementation and Clang was designed to be highly modular and open source without GPL restrictions. I'm not sure why Microsoft have their own frontend but I'm sure it's historical, and even they use EDG for Visual Studio's Intellisense feature, and Clang for a few other things. I'm not aware of any other frontends that are in any way complete/compliant. Typically any compiler you come across will be based on one of the above.
I disagree with his overly complex language design decisions, and his dubious motivations for creating c++, but I couldn't agree with him more on the dangers of mono culture. For that his has an ally in me.
People on Windows most likely use Visual studio and projects like Kdevelop have switched to llvm/clang fully and not regretted it since. That being said, I dont know how usable llvm/clang is actually on Windows, so might be an issue with your system specifically
@@shalokshalom Wrong. LLVM never fully supports windows. The stuff you are using is clang-cl, which is using partial of msvc toolchain. The only real alternative on windows is GCC, not clang. GCC has full support on windows, including libstdc++. Native C++ standard library support for GNU toolchain.
Rust is proof that monoculture is better than competition. A single standard for package management, documentation, compiler errors etc. is better than multiple implementations of all of them. Because what ends up happening is a developer is forced to learn every single implementation in order to be able to integrate and work with others; A huge waste of time.
Rust is proof that monoculture is shit. You can't run Rust on a bunch of embedded systems, arguably where Rust would be most useful, because they don't have LLVM support. You have "trusting trust" vulnerabilities, because there are no alternative frontends (that are anywhere near complete, at least). Cargo is shit - it makes build times slow because people statically link in like 50 different libraries because they think Cargo makes it 'so easy' to dependency manage, meaning that they feel like they don't have to dependency manage properly themselves. Also, Cargo doesn't work with anything else, and the worst part is that no one in the Rust team seems to care. Also, Bjarne mentions "compile time speed" as one of the reasons for wanting multiple implementations. This is the single best argument against your "implementation monoculture" - rustc is hideously fucking slow. You think highly templated C++ is bad? It complies in like one tenth of the speed of Rust. Maybe if we had other Rust compilers, rustc might be faster.
You're confusing standardization and implementation, you don't need to learn every implementation of every compiler as long as you write c++ standard compliant code ! that's why the standard is there for !
@@michaelrosen6478 I'm leaving this comment here so I can come back after running a flamegraph on the Rust compiler and see where the greatest amount of time is spent during compiling.
The most uninteresting comment ever :p Just because he doesn't do screaming RUclipsr nonsense doesn't mean he doesn't care. He clearly asks very intriguing and thoughtful questions. I don't like lex but I like bullshit RUclips comments like yours that do nothing except punch down even less
This is a clip from a conversation with Bjarne Stroustrup from Nov 2019. New full episodes are released once or twice a week and 1-2 new clips or a new non-podcast video is released on all other days. If you enjoy it, subscribe, comment, and share. You can watch the full conversation here: ruclips.net/video/uTxRF5ag27A/видео.html
(more links below)
Podcast full episodes playlist:
ruclips.net/p/PLrAXtmErZgOdP_8GztsuKi9nrraNbKKp4
Podcasts clips playlist:
ruclips.net/p/PLrAXtmErZgOeciFP3CBCIEElOJeitOr41
Podcast website:
lexfridman.com/ai
Podcast on Apple Podcasts (iTunes):
apple.co/2lwqZIr
Podcast on Spotify:
spoti.fi/2nEwCF8
Podcast RSS:
lexfridman.com/category/ai/feed/
"I couldn't write my own linker!" (pauses for a second) "...Actually, I could."
- Bjarne Stroustrup
He wouldn’t have enough time to work on the language if he built 25+ linkers
It brings up an interesting notion. A notion that applies to computer science in the most fundamental way.
The notion of TIME.
Anyone "could" do anything.
A baby "could" eventually write their own linker. Or perform brain surgery, etc.
It's just a question of time and efficiency. He "could" have done it, but would it be worth his time?
1:09
@@dialecticalmonist3405Every baby has done anything a human has ever done! Because they grew, up.
@@dannydk6 Not really. It's a doable task.
The moment when he says: when i designed C++
He's basically God at this point
@@anatheistsopinion9974 Ironic for you to say.
@@pendergastj If I weren't catholic I would say the same
@@pendergastj 😂🔥
@@ollydix The language, as a whole, is so expressive that it tends to introduce more problems(via buggy code) than provisions for solutions. C++ could be one of the most productive programming languages while being the most troublesome at the same time. James Gosling and Bjarne Stroustrup both agreed on that finding when Java started gaining appeal in the mid to late 1990's.
"All this good stuff that we want!" His smile with that reveals a lot.
I was hoping this question would be about the significant differences in machine code/assembly (size and executable speed) between these different compilers - for the SAME destination CPU.
I honestly don't think that would be a productive conversation. Which architecture(s) do we choose to talk about? What program(s) are we compiling for that architecture? Broadly speaking, the major compiler implementations for C++ are the same: they only differ (for the user) when you start comparing specific examples. And when you start getting too specific, you risk your facts getting out of date. All of the implementations are still being worked on.
Absolutlely amazing interview! Bjarne Stroustrup is a living legend and living history.
Its amazing to hear his humble perspective
I love Lex, except he always sounds like he just got up from bed :) Great interview
I noticed a lot of developers have that demeanor I think it's just from sitting too long at a time everyday. He seems pretty cool tho as unlike other developers, he has a LOT of hobbies 👌
No room for drama in technology. That's for the liberal arts.
I wish I spoke that slowly and carefully.
A bit monotone. Wonder what he sounds like when he gets excited.
I initially thought you meant Lex Luther (Bjarne , He would make a great villain ) 😂😂😂
Excellent interview thank you. Two important facts to
do for a responsibly outcome efficiency and reliability. I agree 100% to know the basics in whatever you are going to do.
Gave you the micro knowledge of how things work.
That is, all are good depending on the architecture and system that it will be compiled. But the most complete for sure is the GCC.
Actually in terms of Standard Library, MSVC is the most complete.
In terms of core features GCC and Clang are most complete
Lots od whistles in one video! But really love the conversation ❤️
What a lad. A real hero....
Love your show. I'm not real familiar with some of the vocabulary and I think the words such as front-end, back-end, compiler, etc... are overloaded just enough that it's difficult to find a reasonable explanation on Google. Can you help me understand what front-end / back-end means when talking about compilers? My intuition is suggesting that a compiler is the part of the tool-chain that creates the actual machine code - or possible assembly. I'm not sure if this is synonymous with back-end. And front-end sounds like it's just a parser that streams an AST to any number of backends. So a C++ frontend could write to a C back-end ? Sort of confusing - but I'm quite curious.
front end parses the syntax and generates some sort of intermediate, platform independent representation. Backend takes that IR, and generates native machine code for that architecture/OS and performs optimizations
@@abhinavchavali1443 thanks !! I like your explanation.
I think the last question was misinterpreted ;) Lex was talking about a clean slate C++ language, while Bjarne assumed they were still talking about compilers.
Do you expect a C++ compiler to be written from scratch?
Well, Clang was written from scratch....
No I mean in the last 5 minutes....
Is there any source code analysis information for clang? Or how to read the source code of large projects
What I understood is they're many machines and not all the machines compatible with one single compiler. Is that what Berjan means?
every machine has its own structure and assembly so yeah not every machine is the same
Man Bjarne Stroustrup talks like Derry Murbles from Parks and Rec
And looks like Rick from Rick and Morty
Mono-culture=intel for 10 years.
2:50 "I happen to dislike monocultures." The Rust foundation can afford to do whatever the hell they want because Rust only has one compiler. I think it would be very good if GCC manages to implement a Rust frontend. But there has to be a standard first.
One implemention, one compiler, one c++!
/ Sarc
Linus is his friend
I'm pretty sure that rather sooner than later someone will write a new C++ compiler. And I'm 100% sure that it will be done in Rust. They will claim that it will be supposedly better to do it this way.
Intel became a monoculture.
GCC all day!
GCC is great at taking all day.
@@rakinrahman890 clang SUCKS and only losers use it
@Vishwesh Rajurkar Uh. No it isnt. Visual C++ is the most behind on the standard and is non-conforming. It also produces extremely slow machine code and has limited optimization
@@rakinrahman890 Maybe early versions of Clang. Clang nowadays is just as slow as GCC. Seriously. Have you even compiled anything with either lately?
removing the monoculture from the compiler just moves it to the language
Well CLR is monoculture... atleast its kind of open source now
clr ??
@@yash1152 The Common Language Runtime, basically executes the binary executables that were written in C#
C++ syntax is the worst part about C++
C++ syntax is sooo good
At what point do you just say fuck it and cut it all off
👍
PLEASE HELP ME.
Tillman Island
He mentions 4 frontend compilers (clang gcc, microsoft, edg), but what about Zig, mingw64, llvm, icc? How do these fit in the picture?
Llvm is no compiler?
mingw *is* GCC unless I'm wrong? Minimal GCC?
mingw64 is GCC. LLVM is a backend (which is used by clang), not a frontend. icc, if I remember correctly, use edg as its frontend. And, correct me if I'm wrong, but I don't think zig compiler compiles c++ (it does compile c, though)
Intel's compiler is a back-end designed to produce well optimized machine code for Intel's hardware specifically, similarly to the "embedded" back-ends Bjarne mentions.
Zig CC is built on top of the clang libraries. Mingw64 is a GCC port. LLVM is essentially a set of libraries from which you can build a compiler from and is closely tied with clang which is a set of libraries under the umbrella of the LLVM project for parsing and otherwise manipulating C-family languages. ICC used to be built on EDG but I think they've been transitioning to Clang recently. Essentially, C++ is a language that is not designed to be easy to parse. Its not just a case of building a simple EBNF recursive descent parser. You sometimes have to finish parsing an entire statement before you know what the first few tokens refer to (look up the "most vexing parse" as an example). Because of that it's not worth considering writing your own front end unless you have a really good reason and a lot of resource. EDG is a good commercial option. GCC's aim is to provide a free software implementation and Clang was designed to be highly modular and open source without GPL restrictions. I'm not sure why Microsoft have their own frontend but I'm sure it's historical, and even they use EDG for Visual Studio's Intellisense feature, and Clang for a few other things. I'm not aware of any other frontends that are in any way complete/compliant. Typically any compiler you come across will be based on one of the above.
Jackson Ruth Allen Linda Moore Margaret
I disagree with his overly complex language design decisions, and his dubious motivations for creating c++, but I couldn't agree with him more on the dangers of mono culture. For that his has an ally in me.
Mav Hunter What were his dubious motivations?
Why would you say it's an overly complex language? I'm curious.
so what do you think is not overly complex then you Eva nerd?
Better than that piece of garbage java
@@Artaxerxes. the hell is wrong with java?
Jones Jeffrey Moore William Young Paul
Still GCC. LLVM/Clang is far from actually usable. Especially on windows.
People on Windows most likely use Visual studio and projects like Kdevelop have switched to llvm/clang fully and not regretted it since. That being said, I dont know how usable llvm/clang is actually on Windows, so might be an issue with your system specifically
@@shalokshalom Wrong. LLVM never fully supports windows. The stuff you are using is clang-cl, which is using partial of msvc toolchain.
The only real alternative on windows is GCC, not clang. GCC has full support on windows, including libstdc++. Native C++ standard library support for GNU toolchain.
@@shalokshalom This is GCC I built recently. bitbucket.org/ejsvifq_mabmip/mingw-gcc
@@shalokshalom LLVM is a terrible toolchain. Worst C++20 support.
Lol the browser you are writing this on in Windows is most probably compiled on Clang.
#wan
Microsoft's version routinely breaks and fails to compile anything.
Rust is proof that monoculture is better than competition.
A single standard for package management, documentation, compiler errors etc. is better than multiple implementations of all of them. Because what ends up happening is a developer is forced to learn every single implementation in order to be able to integrate and work with others; A huge waste of time.
Felipe Trzaskowski but they didn’t, because GCC wasn’t interested in that kind of thing. Until clang came along and made it sit up and take notice.
Rust is proof that monoculture is shit. You can't run Rust on a bunch of embedded systems, arguably where Rust would be most useful, because they don't have LLVM support. You have "trusting trust" vulnerabilities, because there are no alternative frontends (that are anywhere near complete, at least). Cargo is shit - it makes build times slow because people statically link in like 50 different libraries because they think Cargo makes it 'so easy' to dependency manage, meaning that they feel like they don't have to dependency manage properly themselves. Also, Cargo doesn't work with anything else, and the worst part is that no one in the Rust team seems to care.
Also, Bjarne mentions "compile time speed" as one of the reasons for wanting multiple implementations. This is the single best argument against your "implementation monoculture" - rustc is hideously fucking slow. You think highly templated C++ is bad? It complies in like one tenth of the speed of Rust.
Maybe if we had other Rust compilers, rustc might be faster.
You're confusing standardization and implementation, you don't need to learn every implementation of every compiler as long as you write c++ standard compliant code ! that's why the standard is there for !
@@michaelrosen6478 I'm leaving this comment here so I can come back after running a flamegraph on the Rust compiler and see where the greatest amount of time is spent during compiling.
@@kylek.3689 Yeah sure I am also waiting when Rust beats C++.
The most uninterested interviewer ever
you're a fool to think that.
The most uninteresting comment ever :p
Just because he doesn't do screaming RUclipsr nonsense doesn't mean he doesn't care. He clearly asks very intriguing and thoughtful questions. I don't like lex but I like bullshit RUclips comments like yours that do nothing except punch down even less