What IMHO Rust does not get right and why I do not use it: long compilation times, high complexity, its syntax, polymorphism based on monomorphization, the requirement for many dependencies to get anything done, an ecosystem susceptible to supply-chain attacks, no ISO standard.
I'm sure I could argue with you about the actual technical differences but this part in particular is very, very stupid.
JTC1/SC22 † shouldn't exist at all. A committee structure is a bad way to do this work, and the practice of having periodic meetings - exclusively in person for much of the time these existed - actually makes it less rather than more useful.
ISO mandates a bunch of rules and procedures which surely make some sense if you're agreeing on thread dimensions for oil pipelines but are completely inappropriate for this work and yet because they're ISO committees the WG14 and WG21 processes are captured.
I don't think it makes good sense to use an SDO for this work, but if you must have an SDO for some reason beyond ego then you could do a lot better than ISO. Check out TC39 for example.
† The C and C++ standards committees are respectively Working Groups 14 and 21 of the Sub-committee on Programming Languages, SC22, of the (First and only) Joint Technical Committee between ISO and the IEC. Yes it's committees all the way down. "This programming language standard could have been an email".
Out of curiosity, what do you think is wrong with monomorphization-based polymorphism? The other alternatives I'm aware of are 1. type-erasure via v-table based dynamic dispatch (which Rust also has in the form of the `dyn` keyword), which has performance and memory-allocation overhead and 2. macros, which Rust also has and, if used for polymorphism, would essentially be like compile-time monomorphization, but clunkier.
Maybe I'm missing something though and there are other alternatives done differently in other languages?
The correct choice IMHO is type-erasure. It does not necessarily have overhead, because optimizers can specialize or devirtualize. Of course, this my depend on how you implement your language, but in C this works nicely. The problem with monomorphization is that it leads to exponential expansion, which later passes of the compiler can not unify again (at least this is much harder than not expanding in the first place). It should also fundamentally limit what you can do, because expansion has to stop at some point, but I haven't thought about this too much.
I also think that where you want monomophization, macro seem fine. I do not think this necessarily has to be clunky, but this is just a guess.
SDL retains everything you've drawn to the screen in backing store. You need to do an SDL_Flip (1.2) or SDL_RenderPresent/SDL_UpdateWindowSurface (2.0) to commit what's in the back buffer to the screen.
I was 4 when computing entered my life. My father was exploring some engine design ideas and used a succession of devices, each more powerful than the last but all proving futile. First it was a scientific calculator, then a programmable scientific calculator. Then he got one of those devices originally made by Sharp but badge-engineered by Radio Shack which they called a "pocket computer"; very calculator-like, but had an alphanumeric keyboard and could store and run BASIC programs written on it with a one-line display.
Ultimately he bit the bullet and went back to Radio Shack to buy the most powerful computer they sold at the time: the TRS-80 Model 16. It was a variant of their TRS-80 Model II business-class computer but with a 68000 daughtercard with a quarter to half a meg of memory. He used this to finally write the engine simulations he'd been planning in his head all along, replete with graphical curve plots and an animation of the piston turning the crankshaft. It ran at about four seconds per frame, but it was still spectacular to behold. I was fascinated. I sat there and watched him type in the programs line by line. I so desperately wanted to poke at it myself, so to keep my grubby mitts off his very expensive machine, my dad went down to Crazy Eddie's and got me a Commodore VIC-20, cheap, for my fifth birthday.
My world had changed.
The VIC-20 came with an easy-to-read manual that introduced new users to the basics of programming with the machine's built-in BASIC, including POKE and PEEK commands that could be used to control its display and sound capabilities. One of the example programs displayed an animated "PETSCII bird" flying across the screen. Even though it was nowhere mentioned in the book, I knew what had to be done: I had to make that bird controllable with cursor keys.
And so I did it. It took me a couple days? few days? But I bent the machine to my will, and I've been chasing that high for 43 years now.
I still remember getting that Pentium as a graduation present, and my room was suffused with the "new computer smell" for a day or two afterward. Ah, glorious.
Historically these weren't "edge cases"; all windowed environments sent a "redraw yourself" event to a window when it needed to be shown after having been covered up, that was handled specially by the application. In X11 this was an Expose event, in Windows this was called WM_PAINT. If you had a fancy X server back in the day, you could enable backing store; this kept a framebuffer of the window contents in memory even if the window itself was covered up that could be quickly restored upon exposure. This was incredibly useful and made redraws fast and glitch-free, but back in the days when RAM was expensive (you know, unlike today...) it could not be relied on in all X implementations. Compositing WMs have the equivalent of backing store for all windows, all the time.
Left arrow was replaced by _, which (in Squeak anyway) is actually an assignment operator, with := as an alias.
Some computers going into the 80s, for example the Commodore 8-bit line starting with the PET and going through the Commodore 128, still had ↑ and ← for ^ and _.
It's the reason I just build a new PC, despite the insane prices, I'd rather overpay than have reasonable prices but no stock to buy. With any luck I'll get 8-10 years out of this one and by then the PC landscape will be something else entirely.
reply