วีดีโอ

Nice intro talk. Now I am interested in looking into Nix

I think it is worth giving some mention that on the front of static typing Rust actually is meaningfully stronger than C++, as C++ number types internally behave like a dynamic typed language, which can turn into surprises.

Exactly what I was looking for Thanks 🙏

Super informative

In the future they will look back at the last 50 years of computer programming and think of it as the Dark Ages: a time of confusion, superstition, tribalism and madness. This is not a joke or a criticism of the lecture. As an industry we are constantly making up new ways of telling ourselves we are in control, but in reality it is a Tower of Babel.

Amazing presentation ❤

Vincent looks like average NPC from Dishnored game. Thanks for the lecture

With all humility, not wishing to imply that I have his greatness (or indeed anything more than glints of occasional competence)... Late in his career, Neil Peart took drum lessons -- in jazz. So it might also be for me, coming from a procedural/object-based background (heavy on the former), as I take the plunge into functional /combinatorial. I find it all very intriguing. Thanks to Conor and everyone for the talks.

I don't like C++ but I do like listening to Kate Gregory.

That fromEnum solution is absolutely awful and haskell does have a count function... Not like you couldn't have defined it yourself

The definition of pure function and distinction isn't really correct. A combinator is a pure function that is not a closure, that's it.

Really good talk!

00:00:12 Rust foundation be like: "What did you just say??? I haven't heard you ask for permission"

Conor is easily one of the best programming speakers! Combinatorial logic and array programming are such interesting subjects. Keep up the great work!

Amazing!

What about any of this is "experimental"? They just took elements from the most popular langauges and put them into their langauge. Its not even that they took parts from several radically different langauges and the combination of those is a unique product, its just a subset of other popular languages. They only call it "experimental" as to qualify their claim of being a successor to Cpp, as to not sound as arrogant.

Same as the new Zig Language you're using the massive LLVM Libraries. An LLVM-only build requires anywhere from 1 to 3 GB of space on any machine. A full build of LLVM and Clang will need around 15 to 20 GB of disk space. The exact space requirements will vary by system but damn. They claim it's so large because of all the debugging information and the fact that the libraries are statically linked into multiple tools. I call that "Organized Despair". No Offence, however just before using Carbon for your own Application Builds, your using a Program that is ten times larger than a Linux Ubuntu OS just to achieve it. You would be much better off to have gone with a Python Like Approach using C++ as a base language with an Interpreter instead right?

I don't know if he's trying to sensationalize this talk or if he's received brain damage in the past couple of years, but there are several "points" he makes that are just wrong. For starters, outside of niche mathematical uses, overflow isn't a problem, and in those instances where it could be a problem you can detect overflow yourself before causing it and thus prevent even the possibility of ill effects. Part of the problem I see relating to it is people not checking user input, and if you're not checking user input then you probably shouldn't be a programmer. As far as sorting floating point data, you can provide your own comparator if you don't like what the default does, but there's nothing in the standard preventing you from calling std::sort() on such arrays. And I'm going to skip all the rest to say that no language should have an unsafe keyword. That's the kind of garbage that gives newbies a false sense of security which causes even worse subtle bugs to crop up. No programming language should constrain programmers like that. Far too many new languages keep popping up that constrain you in ways that prevent valid use cases and try to push this propaganda that it's justified because it prevents bad programs, even though there are whole classes of problems that they do nothing to prevent and which can be far more pernicious than the classes of problems they do prevent. But ultimately, if you want to constrain code that scares you into "unsafe" sections, use a static analyzer, as there are many to pick from, including free and open source analyzers, and just add a comment around that code labeling it unsafe.

Futhark sample: let SumOfSquares a = map2 (\x i -> if length a % (i+1) == 0 then x*x else 0) a (indices a) |> reduce_comm (+) 0 This isn't point free but does use three different combinators. |> could be replaced by reordering with parenthesis, but the map-reduce array combinators are the expected way to handle arrays. The filter was avoided using a neutral element, because realizing the filtered list could cause multiple heavier passes.

Nice talk but wrong in so many ways that I am not interested to discuss. It its a very opinionated talk about what are the strength of C++. Lot's of love for auto but no mentioning what so ever for smart pointers, which are way more important to write sound code. And being standardised isn't really helping in writing good software. It is just helping in writing portable software. And it is somewhat dismissed by available compilers not implementing standards. Most of the time you need to figure out by experiment what your C++ compiler is able to do. Programming languages where there is only one compiler available, which is constructed by the people designing the language, set their standards by implementation. I prefer that way. I never was disappointed by a rust or swift compiler - but I found that I was very dependent on the specific version of gcc or clang to use C++ "standard" features. E.g. C++ has modules since C++20, but even setting your compiler standard to c++23 won't make it work with cmake, as the way to process modules and link to them is very compiler specific. As of now it isn't something to rely on for production code, at least not of production code supposed to be portable. If one goes into the list of supported C++ features of gcc or clang on the internet, one will find a mess. Standards do not help C++ as compiler vendors seem to adopt to them just as they feel like it.

8:40 they did not fix it in post

No one got the joke, 1420 is not 420. 20:55

I simply cannot believe that people are using anything other than C linkage on the API boundary. Using C++ types just leads to eventual misery, and is holding the language back because now nobody wants to break ABI.

Wonderful talk. I completely agree on using asserts and also making sure they don't change algo complexity. For developer time, it is one of the most efficient ways to (partially) verify correctness.

life after c++, it's fun to dream, although I'd be happy if there was only C and assembly, have we ever really needed anything else?

superb talk !!

34:55 most important statement of the whole talk? Because so much other stuff follows from this seemingly innocuous statement.

12:00, *1888. 15:34, what?! Do you know any other kind of software they are willing to pay millions? 38:30, to map true/false keeping their positions/indexes. If that's not required, std::partition puts all trues at the beginning, returning a pointer to where they finish and to where the falses start. And std::stable_partition, despite obviously not keeping their indexes, keep their positions related to each other, at each group. 56:00, auto sum_of_squares (std::vector<int> nums) {return std::accumulate (nums.begin(), nums.end(), 0, [](auto x, auto i) {return !(nums.size() % i)*x*x;});}

Good clear points. On another hand, it's a bit depressing how 20 years of the language went into just getting rid of redundant typing in C++03 for loops with a bunch of new concepts and new syntax. And it skips all the gotchas along the way.

So my take away from all this is that C++ has an ugly syntax, C++ is overly complex, C++ is not safe in anyway. Likely none of this can be fixed. Makes me feel OK that after decades of using C++ I gave up in disgust a few years ago and moved on. It's good to know smarter people than me feel the same.

Hoekstra family sounds like one of the scariest families. Three children who can APL and work with data and numbers.

Is it "undefined behaviour" to use a cursor from one sequence onto another sequence? e.g., `flux::inc(seq2, flux::first(seq1))`

Great explanations. Thank you for sharing❤

At 22:00 I have to question the sanity of a person who writes (or rather generates) such code and calls it a feature of a modern language. If you can't do it in C, you're simply doing it wrong 😉

I owe my career to "this should work". As an autodidactic programmer, everything I've done in my career started out as something I didn't know how to do, but believed it could be done. If I ever really doubted it, I couldn't have accomplished it.

The people asking advice is a fascinating social process. People have all kinds of intuition based reasons they choose who to ask for help. They rarely ask from the person they know is just knowledgeable and good at something. They rarely listen to the person that can build their answer based on known facts and conclusions, mechanics and processes, and is willing to mention the reasons why they give the advice. They often ask from the person others ask from or who has some status. Like a social media influencer. And the shorter and easier the answer, the more likely they are to listen and take it. Like they might know a person who's really into cars and someone who's into psychology, and they ask the person who's into psychology about their car (because that person has a car too). Maybe it's because they expect not to understand the car enthusiasts answer or think the answer's gonna be too in-depth, the car enthusiast might educate them on what's the problem and how to deal with it instead of telling them just to get part X from the local car shop. And sometimes there's a couple of people who are present hearing the question and give their two cents, and the person asking takes the advice that's not reasoned, just thrown out there, and the other people think "well that's not gonna end up in success unfortunately" and see it unfold a bit later. But the social processes decide that had to happen. Or someone gives advice and a reason, but someone is set to do it one way, ends up failing and following the advice, sometimes with "should've listened, you were right".

Yes, with a lot of hoops and tricks you can start reimplementing features of Rust in your C++ code. Or you can just do the logical step and switch to Rust. What the industy is doing anywhay.

So many words... I think it's pretty clear, that it's time to switch to Rust. That is what everyone is doing.

I'm starting to think Sean Parent is like this uncle of C++. Cool and knows all the stuff and is happy to teach. Honestly his points are good. A lot of languages are popping up that are successfully fixing a lot of C/C++ issues. Like the readability of the library and having some sort of teaching tools and exercises to learn to use the language. Or just good material on using the language over reading templated documentation that makes no sense. Languages like Rust and Zig, much, much faster, fixing safety/memory issues, having package managers, having learning tools, brilliant error messages from the compiler. Given that Rust has the con that C++ doesn't: getting the code to actually run is next to impossible, because it holds you responsible of doing it until it's right.

Quite interesting to listen. Very neat speech. Thanks!

:o 🎉

Good presentation!!!

Great talk, thanks! Thanks to your videos I discovered array-stack languages. Here is my uiua version of the pos-neg count. I'm starting to find this language (family) really beautiful. Again thank you! ↥∩/+⊃<>0

41:33 wouldn’t overloading the close_session function just reintroduce the problem which we are trying to solve by using enum classes? Before using enum-> pass the wrong value, underlying type is int-> wrong item gets erased. After using enum + overload -> pass the wrong value, overloaded function gets called, wrong item gets erased, unless we have different implementations for each of the overloaded functions

Thank you for a great talk :)

First solution is a boxing - it's working, for sure, but it have costs, isn't it? Or the compiler can somehow strip away everything except the wrapped string inside the struct?🤔

This talk was so intimidatingly mind-blowingly awesome... Totally didn't expect it to be so interesting!

I don't think there is a better illustration of the unfortunate current design of the ranges filter view than this one.

Alternative title: angry man teaches move semantics

Thanks for this presentation, it really helped me get some of the details right (spefically slide 34)