I ended up switching from Zig to C# for a tiny game project because C# already supports cross-platform hot reload by default. (It’s just `dotnet watch`.) Coupled with cross-compilation, AOT compilation and pretty good C interop, C# has been great so far.
He's right: Markdown was built for web editing in an era where physical keyboards outnumbered virtual ones. It doesn't really make sense for Notes outside of export.
There's little benefit to it as an input system on iOS/iPadOS (likely the dominant platforms for Notes) where formatting menus are just as close as `#` and `_` characters.
Several Markdown rules wouldn't make sense in the context of Notes. e.g. "end a line with two or more spaces then press return to create a <br>", which was designed to accommodate manually hard-wrapped text that Notes users likely don't want. Apple would have to follow something like CommonMark (feels unlikely) or implement their own Apple-flavoured Markdown, leaving you to learn what's supported and discover the quirks — kind of like its partial implementation of vim input in Xcode.
Popular Markdown apps seem to have converged on 'edit on line focus, preview on line blur', which is surely what the Notes app would do, because modal editing with preview and edit modes feels un-Appleish. 'Preview on line blur' _is_ nicer than a separate preview mode if you're a Markdown power user, but it still leaves many quirks you have to learn. (Just today I wrote, '# Thoughts on C#' in Obsidian, which reads ok with the cursor on that line until I pressed enter and the preview became, 'Thoughts on C'. Leaving me to learn I was supposed to know to write '#Thoughts on C\#' in the edit mode.)
Keyboard-accessibility isn't the only advantage of formatting characters.
The most frustrating, throw-my-device-at-the-wall issue with 90% of WYSIWYG text editors, is the insane handling of invisible input states.
- If you begin writing a bold word, but want to delete the first character, the style is reset.
- If you’re writing a list and you want to exit out of it, every editor has a different weird convention of doing that.
- I can’t even begin to describe the amount of broken behavior that is entering code in MS Teams (does Microsoft use Slack internally?)
There are some innovative ideas to solve this, like Bike [^1], but nobody goes to the effort of implementing them. So the easiest, most compatible and most intuitive solution are formatting characters like in Markdown.
Do iOS devices still default to translating consecutive spaces into “. “ within a few seconds? Always used to be a bother when authoring md content on an iPad.
Time isn't that much of a handicap. High-level players just have much better pattern recognition and intuition. It's the same reason they adapt faster to weird positions in Fischer Random than lower-rated classical players.
Even with gaps of 200 points the thinking and play speed difference is acute at high levels, for example in Magnus' playful "too weak, too slow" casual blitz: https://www.youtube.com/watch?v=EY27lgnPKWI
Tube Creature is also cool (the source of the tube paths for this map).
Particularly like the "Tube Tongues" metric — the second-most commonly spoken language after English by residents near each tube station, it paints a real picture of a diverse London:
I don't think books and tutorials help that much. Playing and making games — a lot of games — might help you grow more as a designer than reading and watching YouTube.
1. Do master studies. Take a tiny environment or mechanic of a game you love and reproduce it for education, knowing you'll throw it away. Do this often. Get faster at it.
2. Ask people what their favourite game is. Play it. If it's fun to you, why? If it doesn't resonate with you, why?
3. Internalise the idea that ideas don't matter that much, execution is what matters. Good game designers can make otherwise boring games feel fun to play. (See "the art of screenshake" below.)
4. Make a lot of games. Make them small enough to finish. You don't have to release them all, but you should watch other people play them sometimes.
5. Don't listen to people who tell you not to watch YouTube for game design ideas, there are plenty of great videos out there that have positively changed how I think about game design:
The art of screenshake (starts a little slow, but stick with it!):
+1 for make a lot of small games you can finish. Game jams / hackathons are good for this [1][2]. The fact that OP got their demo in front of people in ~6 weeks is heartening though for that aspect, many people lock themselves away for years only to discover their efforts were ill-advised.
The Go community is more framework-averse, preferring to build things around the standard library and generally reduce third-party dependencies. Go also tends to be used more for backends, services and infrastructure and less for fullstack websites than Ruby/Python/PHP/C#.
Or if you want more Next.JS like, but still fullstack framework there is https://leptos.dev/ and https://dioxuslabs.com/. Maybe dioxus being much more ambitious in its scope (not just web).
People say, “oh, it’s safer than C because tests can warn of missed deinits” but the fact is it isn’t memory safe by design and it’s not a priority for the language.
There are still reasons to use it and there are domains where memory safety isn’t a priority, but memory safety depends on the same mix of linters, code review, simple memory models, a deep understanding of how memory works, minimal dependencies and luck just like in C. Although none of those things will save you on their own or combined. If memory safety is a priority I’d consider other languages.
reply