Threads for jokoon

  1. 7

    The dark secret of STL is that std::vector of non-pointers outperforms everything else in 99.9% of use cases due to cache locality 🤫

    (just watch out for object slicing)

    1. 2

      Eh, you will eventually hit those cases with a ton of inserts and/or deletes on large lists, where vectors will start to struggle. Moving 20k elements by one slot isn’t great if you need to do this several thousand times per second.

      1. 3

        If you have so many inserts, there’s probably a better way.

        If you insert only at the head/tail, there’s deque.

        Do you need to keep a collection in a sorted order? A b-tree set will be faster. If it doesn’t have to be sorted at all times, including construction, then appends to a contiguous vector with a sort at the end will be even faster.

        1. 1

          I have mainly experienced the need for linked lists in the deletion case where your suggestions don’t help. Not many things are better than lists at that. But also do note that some collections do need to be ordered in an arbitrary order that cannot be reproduced without external data, and linked list is the only structure that I know of that can keep that and have good insertion/deletion complexity.

      2. 1

        do you have a source for this?

        1. 1

          Nothing authoritative; this is a performance guideline that is generally true but easy to think up workloads where it’s not (otherwise why would we have the other STL containers?)

          The source I wanted to link was Herb Sutter’s 2014 talk but microsoft has moved the video and nothing can find it anymore. If I remember correctly in that talk he mentioned that random inserts in std::vector beat the performance of std::list (a data type made for random inserts) up until a vector size of around… was it 50kb?

          It’s all about that cache locality.

      1. 1

        C is just simple enough. Python is simple enough, too.

        I use the simplest parts of C++, but a language cannot expect to be adopted if it’s not simple enough to use. It’s the common denominator for all languages.

        1. 1

          C++ has been widely adopted despite its complexity. Java is also complex (considering its ecosystem of frameworks, annotations, DI containers etc.) and it is widely used too. Rust is also comparably complex and is quite popular/hyped. …

        1. 5

          Yes it matters.

          At least with C++ developers can slowly learn the more arcane part of the language language while they use it. A bit more difficult with Rust.

          Furthermore, it might be possible to implement some form of borrow checking for existing languages.

          Any language should be easy to learn. That’s true for C and python. Language popularity is highly correlated with ease of learning. And this is true for all the new languages out there that try to do fancy things: most developers do not care.

          Personally, all I would ever want, is something mostly like C/C++, with pythonic features, easier to read and use, faster to compile, without a GC, statically compiled, without sophisticated things.

          1. 17

            I wouldn’t call C easy to learn. It probably has less essential complexity than Rust has, but there’s still a lot of fiddly details to learn that wouldn’t come up in languages created decades later with garbage collection and better tooling and syntactic defaults.

            1. 9

              A couple issues I found when wanting to learn C is all of the variation because of its history. What tooling should I use? Which conventions should I follow? Which version is the current version?

              The various C standards are not conveniently discoverable and even when you map them out, they’re written in reference to past standards. So to get the set of rules you have to mentally diff K&R C with a handful of other standards published over 40 years, etc. Starting completely from no knowledge and trying to figure out “What are the complete set of rules for the most modern version of C?” is nearly impossible. At least that has been my experience and biggest struggle when trying to get started with C multiple times over the years.

              Then I constantly see veteran C programmers arguing with each other about correct form, there seems to be far less consensus than with modern languages.

              1. 5

                I’d say C is easy to learn but hard to master. But that could be said about a lot of languages.

                1. 2

                  I think there is a big difference to what is the absolute minimum you can learn.

                  You can “learn” C with programs that compile and run the happy path mostly correctly. The probably have tons of bugs and security issues but you are using the language.

                  Rust forces you to handle these issues up front. This does make the minimal learning longer but the total learning to be a “production ready coder” is probably actually shorter.

                2. 15

                  Man, I was terrified when I was learning C++. I would stick to the parts I was “comfortable” with, but when I would call someone else’s code (or a library) I couldn’t reliably know how the features they used would intersect with mine. And the consequences very often were debugging core dumps for hours. I’m no Rust fanboy, but if you’re going to have a language as complicated as Rust or C++, I’d rather learn with one that slaps my hand when doing something I probably oughtn’t do.

                  1. 11

                    So, Nim once ARC lands?

                    1. 3

                      Is that not the case already ? I unfortunately do not use Nim often these days so I might be out of touch, but if I recall correctly arc/orc are available but not the default.

                      EDIT: Yeah, It seems to use ref counting by default currently but the doc advise to use orc for newly written code Cf:

                    2. 8

                      Any language should be easy to learn. That’s true for C and python. Language popularity is highly correlated with ease of learning.

                      All other things being equal, yes, ease of learning is good. But at some point one may have to sacrifice ease of learning to make the expert’s work easier or more reliable or faster or leaner. Sometimes that’s what has to be done to reach the level of quality we require.

                      If it means some programmers can’t use it, so be it. It’s okay to keep the incompetents out.

                      1. 8

                        I was mostly with you, but “incompetents” is harsh.

                        1. 4

                          Can we at least agree that there is such a thing as incompetent programmers? I’m all for inclusivity, but at some point the job has to get done. Also, people can learn. It’s not always easy, but it’s rarely impossible.

                          1. 4

                            There are, but generally they’re not going to be successful whether they use Rust or another language. There are inexperienced developers who aren’t incompetent but just haven’t learned yet who will have an easier time learning some languages than Rust, and there are also experienced programmers who simply don’t know Rust who will also have an easier time learning other languages than Rust. Since the incompetent programmers will fail with or without Rust, it seemed like you were referring to the other groups as incompetent.

                            1. 5

                              Ah, the permanent connotation of “incompetent” eluded me. I was including people who are not competent yet. You only want to keep them out until they become competent.

                              My original point was the hypothesis that sometimes, being expert friendly means being beginner hostile to some extent. While it is possible (and desirable) to lower the learning curve as much as we reasonably can, it’s rarely possible to flatten it down to zero, and in some cases, it just has to be steep.

                              Take oscilloscopes for instance. The ones I was exposed to in high school were very simple. But the modern stuff I see now is just pouring buttons all over the place like a freaking airliner! That makes them much scarier to me, who have very little skill in electronics. But I also suspect all these buttons are actually valuable to experts, who may have lots of ways to test a wide variety of circuits. And those button give them a more direct access to all that goodness.

                              In the end, the question is, are steep learning curve worth it? I believe that in some cases, they are.

                              1. 3

                                That makes sense. Thanks for clarifying. I don’t know if I have a strong opinion, but I do believe that there are cases that require extreme performance and that often requires expertise. Moreover, having been a C++ programmer for a time, I’m grateful that where C++ would accept a broken program, Rust slaps my hand.

                        2. 2

                          True. Ada Programming language easy to learn but not widely accepted or used

                        3. 4

                          At least with C++ developers can slowly learn the more arcane part of the language language while they use it. A bit more difficult with Rust.

                          I’m not sure what parts of Rust you consider “arcane”. The tough parts to learn, borrow checking and lifetimes, aren’t “arcane” parts of Rust; they are basically it’s raison d’être.

                          Any language should be easy to learn.

                          Ideally languages would be as simple/easy as they can be to meet their goals. But a language might be the easiest-to-learn expression of a particular set of goals and still be tough to learn – it depends on the goals. Some goals might have a lot of inherent complexity.

                          1. 3

                            If carefully aware of escape analyses as a programmer, you might realize that with Go, and, while programming Go for several years, I’m by no means a Go fanboy.

                            In particular, I conjecture that you could write a program in Go that does not use GC, unless the standard library functions you use themselves use GC.

                            I need to learn Rust, i realize, having written that prior sentence, and having been originally a C fan.

                            1. 6

                              Personally, I would strongly recommend the O’Reilly “Programming Rust, 2nd ed.” For me it was a breakthrough that finally allowed me to write Rust and not get stuck. It may not be “perfectly shiny” what I write, but before that, I often stumbled into some situations I just couldn’t get out of. Now I understand enough to be able to at least find some workaround - ugly or not, but it lets me go on writing.

                              Also, coming from Go (with a history of C++ long ago beforehand), one thing I had to get over and understand “philosophically” was the apparent lack of simplicity in Rust. For this, my “a ha” moment was realizing, that the two languages make different choices in a priorities triangle of: simplicity vs. performance vs. security. Go does value all 3, but chooses simplicity as the highest among them (thus GC, nulls, etc; but super approachable lang spec and stdlib APIs and docs). Rust does value all 3 too, but chooses performance AND security as the highest. Thus simplicity necessarily is just forced to the back-seat, with a “sorry, man; yes, we do care about you, but now just please stay there for a sec and let us carry out the quarrel we’re having here; we’ll come back to you soon and really try to look into what you’d like us to hear.” And notably the “AND” here is IMO a rather amazing feat, where before I’d assume it just has to often be an “or”. Also this theory rather nicely explains to me the sparking and heated arguments around the use of unsafe in the community - it would appear to happen around the lines where the “AND” is, or looks like it is, kind of stretching/cracking.

                            2. 2

                              Personally, all I would ever want, is something mostly like C/C++, with pythonic features, easier to read and use, faster to compile, without a GC, statically compiled, without sophisticated things.

                              I think you’re looking for Myddin (still WIP) or possibly Hare. Whether they’re “pythonic” is debatable though.

                              1. 1

                                Any language should be easy to learn.

                                Not only easy to run. Easy. Because why would one make it difficult if it clearly can be made easy? The whole point of programming languages is providing simoler alternatives to the targets of their compilers.

                              1. 1

                                GDScript seems to be quite fast, but it lacking a lot of syntax sugar. I wonder if it can be compared to python in a benchmark.

                                1. 3

                                  Working on my game code, I’m still refactoring things. Code is quite awkward right now. (I’m unemployed in france right now).

                                  Currently it’s aimed to be a shipping/factory game, a bit like factorio, but with many more items, with population, and without belt or inserters, so a bit easier to manage.

                                  I also tried to generate a call graph using ctags and python, but I epic-failed (it’s non trivial to resolve function calls, and using regex yielded horrors). I’m not really willing to use other tools to do this (requires clang and other heavy tools).