TL;DR I used Monte-Carlo simulations + Elo-based win probability estimation to find the probability of Hikaru and other top players scoring very long win streaks (e.g. 55+ consecutive wins) over a year after Kramnik's allegations that Hikaru Nakamura might have cheated based on a number of performances. Initially I thought such streaks are indeed statistical anomalies, but it turned out to be extremely probable: Hikaru scoring at least 55 wins in a row over a course of 3000+ online blitz 3+0 games this year is about 98.4%
That is likely based on large sample size (3k+ games in 3+0 blitz only this year, 35k blitz games over lifetime just on Chess.com), Hikaru being highly skilled (consistently top 1-2 ranked blitz player both over the board and online) and low opposition rating (as compared to other top 5 blitz players on Chess.com: Magnus Carlsen, Nihal Sarin and Daniel Naroditsky).
I love Bevy, but I feel like it's still more of a Game Development Library rather than an engine. Godot, on the other hand, looks very nice in terms of user experience: great editor and very easy to understand and use. Will Bevy implement a first-party editor, overhaul of game development experience etc or is the goal to only support these things with third-party plugins and crates?
Building an editor is one of our highest priorities. We've been laying the groundwork for this for awhile and we would like to have tangible progress here within the year. We can't commit to specific dates, but know that a full editor experience is a central part of our plan. Code-only will always be an option, but we firmly believe that visual editing is a critical piece of the gamedev puzzle.
A first-party editor is planned and Bevy's UI library and other infrastructure is getting to the point where it might to start to materialise in a few releases. However, I personally love the code-first experience Bevy offers in comparison to something like Godot.
Godot is just AWESOME, I am very impressed with the progress the team makes and the overall direction of the project.
I was always excited about Game Dev (even started learning Computer Science and became a Software Engineer largely because I wanted to make games), dreamed of making my own small games but never really got to it. After I became a full-time Software Engineer, I never really found time or the right tools for making my own small games for fun. I recently discovered Bevy and gave it a try. ECS is a nice concept, but Bevy is more of a library and it's quite hard to make full-featured games using it (just like using SDL/something similar).
When I discovered Godot and gave it a try, I was so impressed: it's really nice for beginners, yet performant enough and has amazing community. This is exactly what I wanted to find, so I'm incredibly happy it exists and am very excited about the future development of Godot.
One thing I wish was different is choosing a different language as the native and "official" one. GDScript is OK and arguably pretty good Python-like language for beginners and rapid prototyping, C# is OK and is probably very nice to have because many people would be happy to switch from Unity, but I personally would be happier with either better C++ support (which I know exists in GDNative interface which was improved in 4.0) or something else.
C# is a fine language, but I have a feeling it has so much presence in GameDev just because of Unity. It's way too verbose and the tooling isn't as good (outside of full Visual Studio which I have no desire to use), but maybe "actual programming" part of GameDev isn't as important and I should just give in/use GDScript.
Yeah, I've seen those and I'm happy Godot moves in this direction, but using these tools would steer me away from the "default" and "primary" behavior, I'd potentially face more bugs/awkward development setups.
It might be worth if I'm serious about Game Development and ready to invest time and effort into customizing the tools, but what I'm looking for is "out of the box" experience which will make it easier for me to solve problems that I face (e.g. if I ask questions more people would be able to answer/help), the tutorials/resources I find will be more applicable etc.
As others mentioned in this thread, having first-class support for a language isn't the same as providing API for plugins and custom scripts.
I wish Godot chose a real existing programming language instead of building their own DSL. Even Lua might have been a decent choice, although I hate the syntax.
> Latex is "typesetting-complete". This language is not, so it's not a replacement.
Based the documentation (and the title), it isn't meant to be _a replacement_, but rather _an alternative_ and that's totally OK. Not everything needs a drop-in replacement.
I understand that, just like any tool that has sufficiently many users, (La)TeX grew exponentially in terms of the number of features it has. I like the its core, and I also like the ability to write scientific texts somewhat conveniently. I haven't used Typst yet, but it looks to be something I wanted for quite a while: similar convenience to LaTeX and yet much more simplicity.
To be fair, though, Markdown + KaTeX and MathJax are kind of everything I need right now. Jupyter Notebooks can render enough LaTeX formulas for me to use it when I needed it, even in the university when I'm writing some CS algorithm overview/tutorial or need to do some calculations and hand it in with the explanation. Whenever we had labs in Physics I would do all the calculations in Jupyter Notebooks and that actually looked pretty good. And for my personal blog, I just set up the KaTeX + Hugo which I love: the convenience of Markdown + LaTeX is enough.
This being said, I'm sure there are many people who still have to write papers and would find it useful, but at least for me LaTeX is not a standalone tool that I would use anymore.
Also, part of the value that LaTeX has is an enormous amount of templates that I don't understand but I use them because I have to (e.g. when writing a thesis - it has all the right typesetting, formatting and so on) or because they look very good (I still maintain my Resume in LaTeX format. This is hard to replicate or capture with a new system.
EDIT: Oh, and also Mermaid.js which is now integrated into both GitHub Markdown and Hugo is wonderful for a very small version of TikZ. Although, it is very inconvenient for my taste, but it's still very useful.
I worked in Germany for a while and one of such unions was built at my company. I can't think of a single good thing they did and I remember plenty of ways they made the life of employees worse in ways that looked deliberate. The way the union/council was built looked very bad to me to the point where I completely stopped following the office politics.
I'm not saying this is a bad idea and I certainly don't have enough knowledge of the German system to have an objective assessment, but this looks like another example where the law is produced with good intentions but the implementations of such rules are serving some other purpose.
Other than that, I felt like Germany has incredibly good laws for the workers/employees, the working culture there is very healthy and I like it a lot.
This is exciting! I see a lot of familiar pieces here that propagated from Google's Code Search and I know few people from Code Search went to GitHub, probably specifically to work on this. I always wondered why GitHub didn't invest into a decent code searching features, but I'm happy it finally gets to the State of the Art one step at a time. Some of the folks going to GitHub to work on this I know are just incredible and I have no doubt GitHub's code search will be amazing.
I also worked on something similar to the search engine that is described here for the purposes of making auto-complete fast for C++ in Clangd. That was my intern project back in 2018 and it was very successful in reducing the delays and latencies in the auto-complete pipeline. That project was a lot of fun and was also based on Russ Cox's original Google Code Search trigram index. My implementation of the index is still largely untouched and is a hot path of Clangd. I made a huge effort to document it as much as I can and the code is, I believe, very readable (although I'm obviously very biased because I spent a loot of time with it).
I also wrote a... very long design document about how exactly this works, so if you're interested in understanding the internals of a code search engine, you can check it out:
I've seen this before and there are great courses, but most of them cover the basics.
What I tried to find for myself is a bunch of in-depth courses that cover the areas where I'm not as comfortable. I've started collecting some courses (there were especially many in the COVID era simply because the universities recorded the courses anyway and only needed to upload them), books and papers. I didn't aim to get a comprehensive set of resources covering everything or having some specific features, I simply gathered what I thought is interesting for myself:
That is likely based on large sample size (3k+ games in 3+0 blitz only this year, 35k blitz games over lifetime just on Chess.com), Hikaru being highly skilled (consistently top 1-2 ranked blitz player both over the board and online) and low opposition rating (as compared to other top 5 blitz players on Chess.com: Magnus Carlsen, Nihal Sarin and Daniel Naroditsky).
There's also a discussion and short summary on Reddit (https://www.reddit.com/r/chess/comments/1873ohw/analyzing_hi...)