1. 1

    I’m mostly working on trying to create an alternative game client for an old classic MMORPG game that was part of more than a decade of my life — Ragnarök Online. You can hardly call it a client though, since I’m just finished with parsing GRF files, loading and actually rendering sprites. The work is more directed towards what will potentially be a GRF Explorer app in the more realistic and near future.

    Also, during some spare time I still work on creating an app like GitHub and SourceHut, but that’s also still in its very early stages. Not sure it would really be interesting to anyone.

    And last, I have been back streaming, and during those I worked on both projects, but mostly the first one.

    1. 2

      Razer Blackwidow (Tournament Edition)

      1. 5

        Yet the new fs API doesn’t support contexts at all, so you have to embed them in your fs struct.

        1. 9

          The io package in general doesn’t support contexts (io.Reader and io.Writer are examples of this), and they’re a bit of a pain to adapt. In particular, file IO on Linux is blocking, so there’s no true way to interrupt it with a context. Most of the adapters I’ve seen use ctx.Deadline() to get the deadline, but even that isn’t good enough because a context can be cancelled directly. I’d imagine that’s why it’s not in the fs interfaces.

          For every Reader/Writer that doesn’t support Context directly, you need a goroutine running to adapt it which is not ideal. There is some magic you can do with net.Conn (or rather *net.TCPConn) because of SetDeadline, but even those would need a goroutine and other types like fs.File (and *os.File) would leave the Read or Write running in the background until it completes which opens you up to all sorts of issues.

          1. 1

            You can you use the fs.FS interface it to implement something like a frontend for WebDav, “SSH filesystem”, and so forth, where the need for a context and timeouts is a bit more acute than just filesystem access. This actually also applies to io.Reader etc.

          2. 1

            I’m not entirely sure why the new fs package API doesn’t support contexts, but you could potentially write a simple wrapper for that same API which does, exposing a new API with methods like WithContext, maybe?

            Especially considering what the documentation for context states:

            Contexts should not be stored inside a struct type, but instead passed to each function that needs it.

            But ideally I’d like to see context supported in the new fs package too.

          1. 2

            The only two things that keep me on Windows are games and OBS.

            1. 9

              OBS works on Linux and Mac too

              1. 1

                What sort of OBS problems have you been having on Linux? I use OBS on both and the experience has seemed the same to me. Maybe there’s stuff on Windows that I’m not even aware that I’m missing.

                1. 2

                  Last time I used it, the builtin browser was missing. Also on macOS the audio stuff is clunkier, you need third party apps to create virtual audio devices and connect them manually to sources. I don’t know what’s the status of audio stuff on linux.

                  In general I have the impression that OBS is developed “windows-first”.

                  1. 1

                    I’m not a sophisticated OBS user, but it’s generally worked fine for me on Linux.

                  2. 1

                    I’m also using it on linux. But for example the virtualcam plugin is windows only.

                1. 8

                  I was initially worried that they dropped the “we will never break your old programs” promise but that is not the case.

                  https://github.com/golang/go/issues/40025

                  Obviously we cannot delete these three from io/ioutil. But we can move the implementations to io and leave wrappers behind. That will be easier for new users, and it lets more packages do general I/O without a dependency on os.

                  1. 1

                    Though I consider it to be a bit silly, it seems they plan to retain the package in a deprecated state (for forever?).

                    1. 1

                      I believe they will eventually remove it from newer versions as adoption gets wider spread.

                      1. 12

                        A future hypothetical “Go 2” might; the Go 1 compatibility promise is pretty clear that any program written in any version of Go 1 should always work with newer Go 1 versions (with a few exceptions that don’t apply here).

                        As I mentioned the other day, there are already a bunch of deprecated/frozen packages that aren’t removed for exactly this reason.

                        1. 3

                          Yeah, this is the problem with standard libraries. They have to stay on “semver v1” forever. You better get everything right on the first try, because everything has to be maintained forever.

                          I wish languages treated their standard library like every other package. 3rd party packages can exist in multiple versions, so semver-major changes are only a migration, and don’t have to break anyone.

                          1. 10

                            I wish languages treated their standard library like every other package. 3rd party packages can exist in multiple versions, so semver-major changes are only a migration, and don’t have to break anyone.

                            I am so glad Go doesn’t work this way. It means there aren’t “eras” of codebases that utilize totally different subsets of language features.

                            1. 10

                              Go absolutely has that. One prominent example is code written before the context package and code written after it.

                              And tooling wise, there are projects before Go modules and projects after it.

                              1. 3

                                That’s missing the point. Code written before the context package will work when copied and pasted, patched, incrementally migrated, or otherwise mingled into code written after the context package.

                                1. 7

                                  That’s a good difference to point out, sure. But I don’t think it means my comment has missed the point. There are still costs associated with shifting subsets of the language/std beyond the ability to copy & paste. Look at net/rpc. It is at best unwise and at worst unusable in the code that uses and relies on context cancellation. Because it is a package written in a different era of Go.

                                2. 1

                                  Technically, yes; effectively, I don’t think so. Changes to the stdlib and tooling are infrequent, and almost always come as additions, rarely depreciations, and almost never iterations on existing idioms. Go code will still bit rot over time but I think it is categorically different than the e.g. Rust ecosystem.

                                  1. 2

                                    Rust code bitrots faster than Go code. Absolutely yes. But I don’t think there is a category difference. It’s a difference of degree. That’s a feature of Go that I appreciate, as the churn in the Rust ecosystem annoys me. And IMO, there is not nearly as much appreciation for the annoyance of churn in Rust’s culture as there is in Go’s culture. I would say the difference in philosophy here is probably a category change.

                                    But my point is that Go has eras too. Best not to thumb your nose at the idea. Maybe thumb your nose at the frequency or scale of changes instead. The point is that churn/eras still happens in the Go ecosystem. I’ve lived through it since Go 1.0.

                                3. 3

                                  Just because you don’t name the “eras”, it doesn’t mean they don’t exist. You still have deprecated features. There will be “still using ioutil” codebases, and “moved off ioutil” codebases (and such implicit “era” for every other deprecated feature). There are always some laggards — that’s the reason why the no-breaking-changes promise exists.

                                4. 4

                                  This isn’t a problem, it’s a benefit. I don’t want to have to rewrite my code to the flavor of the day if I want to use a new feature. Compatibility breaks in widely used libraries should come with a heavy burden of necessity.

                                  Even outside of the standard library, an attempt at compatible evolution is a big benefit.

                                  1. 1

                                    The reason that isn’t done is because the standard library contains a lot of glue, just like the language itself does. Major “non-standard” libraries with data structures that get used as API parts don’t want to make breaking changes for the same reason Python 3 was so painful. Everybody has to upgrade at once.

                                    This isn’t as much of a problem for Go interfaces, which are structurally typed, but it’s a serious problem for struct, which is nominally-typed. Plenty of Go functions, even in the standard library, accept struct parameters.

                                  2. 2

                                    Go (and Rust) seems to be rather amateurish in that regard.

                                    Having no actual removal policy is only one step above an “ignore compat” free-for-all.

                                    1. 7

                                      Wait, ‘maintain guaranteed compatibility’ is only one step above ‘ignore compatibility’? Sounds backwards to me.

                                      1. 0

                                        You think ‘ignore compatibility’ should be above ‘maintain guaranteed compatibility’?

                                        (I don’t really care, I think both are playing at roughly the same amateur level, i. e. we should do much better in the 21st century than that.)

                                        1. 2

                                          What do you propose? Which ecosystems out there do this right, in your opinion?

                              1. 3

                                Still parsing Ragnarök Online files (currently .grf, .spr) as part of my project of writting an actual alternative client for the game, which envisions to have modern features and multi-platform support. Specifically, I’m working on the .spr files which basically contain the texture atlas of the game sprites.

                                Also, working on a blog post to document the whole process.

                                1. 1

                                  Sounds interesting. What language are you writing a client in?

                                  1. 1

                                    In Go, but I’m only parsing the data files for now, the client work will start as soon as I manage to finish that.

                                1. 3

                                  Parsing Ragnarök Online files (currently .grf, .spr) as part of my project of writting an actual alternative client for the game, which envisions to have modern features and multi-platform support.

                                  1. 16

                                    Here is the issue where this all started. Here is the library documentation that had the error, and you can now see it’s fixed and links to git.sr.ht. I feel like I’ve seen Drew harass OSS developers on GitHub far too often.

                                    Here is the actual source code that contains the regexps filters for domains. One thing to note here is that it assumes any site beginning with gitlab., gittea., or gogs. is a valid instance of those git services, which is in direct contrast to what Drew tell us. He paints this as a malicious attack on decentralized git instances, when you are free to name your git instance appropriately or submit a change that adds your domain. This seems very standard for the service pkg.go.dev is providing, and I don’t think this flamebait is useful.

                                    1. 9

                                      you are free to name your git instance appropriately

                                      s/free/constrained/

                                      This assumption doesn’t hold in practice. See e.g. salsa.debian.org or source.puri.sm.

                                      or submit a change that adds your domain

                                      This doesn’t really fly. If I host a small instance of GitLab/sr.ht/Gitea I don’t want to chase down each programming language specific tooling requiring a special case for my instance, and wait for the changes to propagate in releases etc.

                                      1. 5

                                        The entire thing is that just the source code links don’t work for self-hosted instances; this is not great, but certainly quite a bit different than the entire repo not working as the article makes it out to be. When I pointed this out on HN last night I got handwaving “but Google sucks!” replies first, and a slew personal insults when I pressed the matter.

                                        This is the kind of attitude these things are written with… meh. But hey, “Google bad” confirmation bias makes it get to the front page anyway 🤷‍♂️

                                        There’s is some valid criticism here, as the entire way this works is kinda hacky and confusing; but it worked like that on godoc.org too, which was originally developed outside of Google. It might be a good idea to improve on that, but I can’t blame the devs for continuing on what’s already here, rather than taking the initiative to develop an entire new specification for this. If you feel such a thing is vitally important then maybe create it?

                                        I’ve got a few other gripes with pkg.go.dev as well, but wrapping it all in an article like this isn’t helping anything. Indeed, if anything it’s going to put the developers in the defensive.

                                        I feel like I’ve seen Drew harass OSS developers on GitHub far too often.

                                        Well, that was a fun read 🙃 (that wm4 fella doesn’t seem … very pleasant … either)

                                        1. 1

                                          Thanks for sharing this. I’ve always had a feeling about the way he communicated and expressed himself, but this made it a lot more clear!

                                          1. -5

                                            Thanks, that made me uninstall mpv.

                                            Looking for a new “simple” video player that doesn’t shit into my $HOME now!

                                          1. 2

                                            I would love to read it, but I have to pay to do so…

                                            1. 2

                                              I like the reference to one of the most classic Dutch cannabis strains.

                                              1. 2

                                                I’m working on a few different things:

                                                • My personal website (mostly a blog)
                                                • A project based around git repos
                                                • An event-store database
                                                1. 23

                                                  It only works in Google Chrome and Microsoft Chrome, unfortunately:

                                                  For the best experience with Codespaces, we recommend using a Chromium-based browser, like Google Chrome or Microsoft Edge. Firefox is currently unsupported, and there are known issues using Safari.

                                                  1. 12

                                                    Codespaces allows you to develop in the cloud instead of locally. Developers can contribute from anywhere, on any machine, including tablets or Chromebooks

                                                    …and on iOS all browsers including Chrome use the Safari rendering engine so this doesn’t really open up development on the most popular tablet platform at all.

                                                    1. 1

                                                      I imagine they will add that.

                                                    2. 4

                                                      Before that note is this paragraph, though:

                                                      During the beta, functionality is limited.

                                                      So hopefully once it’s actually released it will be usable in every browser.

                                                      1. 1

                                                        It only works in Google Chrome and Microsoft Chrome, unfortunately:

                                                        To be honest, it’s quite scary to run all of that inside a browser. Can you imagine the performance on that?

                                                        1. 1

                                                          It probably performs fine on most development machines, to be fair.