I got to try the VOID Star Wars attraction shown in the video (although it might have been set up in a smaller space than the Disneyland installation).
It was a short, scripted, minimally interactive experience. The hand and prop tracking were pretty glitchy and somewhat immersion-breaking. The equipment was heavy and ridiculously cumbersome (even compared to current consumer VR headsets). I'm sure the cost/work of setting up a system like that is basically prohibitive too.
I don't think it's a great reference point for predicting the VR market in the next 5 years or so, as the cost comes down and more polished and inexpensive mass-market systems come out (like the Oculus Quest) that are cordless with good tracking.
Millions of people spend huge amounts of time playing games on tiny rectangles they hold in their hands. I think it's overly skeptical to assume they won't want holodecks, if the cost is $400 and the HW/SW isn't terrible.
I expect it'll at least be an increasingly less-niche gaming platform as not-terrible standalone devices come out (I tried a tennis game that was pretty fun, I'm not a gamer but I could see myself playing some VR games if it was a way to get real exercise).
The current non-gaming uses like corporate/sports/military training probably will grow too as the quality and ergonomics improve.
I'd really like to try a system with good body/face/eye tracking. I think that is kind of the minimum for social applications with really huge appeal. It's hard to get an idea of if it's compelling or not (or how far away it is, what needs to be improved, etc) without trying it though.
Maybe you've already ruled it out, but it might also be worth considering the Kinesis Freestyle line too. I've been using one for many years now after trying it at work and have been pretty happy with it. Since the layout isn't too different it's also easy to switch back and forth with regular keyboards. They have new bluetooth/mechanical versions now too.
I use it tented up in the middle at about 30 degrees with an accessory. The setup isn't very portable though.
For fun, Scheme/Lisp. Once you have macros it really feels like the sky is the limit in terms of what you can express.
I've also been liking Go quite a bit recently. I know it's a language HN loves to hate. It's not as expressive as some other languages. But I feel like creativity within constraints can also be rewarding (kind of like writing a haiku). If I can find a way to reformulate my problem so that it can be expressed easily in Go, I'm often happy with the result. And because the abstractions Go provides are not very costly, it usually executes efficiently too.
It's hard to find a language that combines high level features with the lower level features that performance-sensitive apps often need (like value types, control of memory layout, etc). Also GC simplifies a lot of things, and Go makes it practical for a wider class of applications with sub-ms pauses and making it easy to minimize allocations. C++/Rust involve more programmer effort around ownership, and C# can also involve more programmer effort since minimizing allocations is trickier and GC impact is greater. It's not a big language but the combination of features / trade offs seems really practical.
Go's also widely used enough where you don't need to worry about having a robust library if you need HTTP2 or something.
I agree it's too early to say. I don't think we can just look at a timeline though... we'll at least need to know what the next big market is, before we can say they lost their ambition/ability or waited too long. Even the iPod depended on hard drive miniaturization for example, it probably wasn't possible years earlier.
I'm not sure about (1), although Google's infrastructure not making it an internal priority seems plausible. I also think for Go it's more common to build directly on top of the standard library than in many other languages.
For (2), dep was endorsed only as the "official experiment", whatever that means. It looks like they went with a different design for a bunch of specific technical reasons outlined in these blog posts. According to the last one there are 67(!) pages of content. I'd recommend at least reading part 3 though, "Semantic Import Versioning".
The main advantage of the new system seems to be that it handles major version upgrades in a way that doesn't leave the user exposed to difficult build problems in situations involving shared dependencies. As a trade off, it makes it a little less convenient to upgrade major versions (since the import paths change), although I'm sure tooling can make this easier.
I like a lot of the properties of it: builds should rarely break, the whole system is pretty easy to understand, you can make API v1 a wrapper for API v2 (so users who haven't migrated get the new implementation), you get library versions with the dependencies they were tested with, backwards compatibility is encouraged, a single module can't force you to use old versions of sub-packages (only upgrade), no lock files are needed since builds will be stable without them, it's easy to upgrade but done explicitly, and so on... I guess the main thing is it would be nice if it was around earlier!
Hopefully the transition from dep will be pretty smooth (I believe they are contracting with the main dep author to help with this). I think the vgo prototype already uses some information from other Go package managers (not only dep).
Yeah, it's just the import path that it's changed, but it's still ugly as sin and makes the mapping between import paths and filesystem paths non-trivial.
I think the main example in the article is talking about incompatible types, not global variables, so the issues apply more or less the same in any language (Java, Python, C++, etc), since there is generally no guarantee that one version of a library can work with objects of another version of a library at run time (since the private fields may be different between the two versions).
There's a brief note on singleton problems, so that might be an issue with code that uses them more, but the example given (listening on port 80) is also more or less language independent, since there is only one port 80 whether your code uses singletons or not.
Well, the article calls for a v0, which seems to be exactly for the use case you describe? There are no import path changes, undergoing "rapid, breaking change" is allowed, and if you ever find a good local optimum you can graduate to v1 without any import path change either. I don't see any requirement to ever move to v1, although users may understandably prefer libraries that do. I don't quite understand what additional support you are looking for from "a good package manager".
I'm also not sure this makes it harder to ship a v2. Sure, users will have to change their import paths, although I'm sure tooling like GoLand can easily automate this. But this also frees library maintainers to do extensive API redesigns, without worrying about breaking everything or hanging their existing users out to dry. In particular, the ability to make v1 depend on (and become a wrapper for) v2 is quite nice. Not only does this pattern not break existing code, but it even allows users who have not yet migrated to the new API to benefit from the active development on the latest branch. And of course there is the potential for some degree of automated migration, through inlining wrapper functions as mentioned in the article.
This could still become a problem (if each dependency statically bundles its own dependencies) if any of the types are exposed in an API. For example say there is a Twitch and Facebook SDK that both expose a SetUserProfile(Image) function, and Image is provided by a third library (that is used by both SDKs).
If both SDKs use different versions of the Image library, the internals of the Image struct may have changed (maybe they added support for black and white images). Even though the change may be backwards compatible at a source code level, an Image struct v1.15 wouldn't work as an Image struct v1.16 unless it had the same internal private fields (and they were used in the same way).
Now, your code that loads an Image from disk can't work. It will either use v1.15 and be compatible with Twitch, or use 1.16 and be compatible with Facebook, but not both. A shared dependency works around this issue as long as the changes are backwards compatible - in this case Go would see that the minimum required version is v1.16 and both SDKs (and your code) would use that (or a newer version if you list it as a requirement).
It was a short, scripted, minimally interactive experience. The hand and prop tracking were pretty glitchy and somewhat immersion-breaking. The equipment was heavy and ridiculously cumbersome (even compared to current consumer VR headsets). I'm sure the cost/work of setting up a system like that is basically prohibitive too.
I don't think it's a great reference point for predicting the VR market in the next 5 years or so, as the cost comes down and more polished and inexpensive mass-market systems come out (like the Oculus Quest) that are cordless with good tracking.
Millions of people spend huge amounts of time playing games on tiny rectangles they hold in their hands. I think it's overly skeptical to assume they won't want holodecks, if the cost is $400 and the HW/SW isn't terrible.
I expect it'll at least be an increasingly less-niche gaming platform as not-terrible standalone devices come out (I tried a tennis game that was pretty fun, I'm not a gamer but I could see myself playing some VR games if it was a way to get real exercise).
The current non-gaming uses like corporate/sports/military training probably will grow too as the quality and ergonomics improve.
I'd really like to try a system with good body/face/eye tracking. I think that is kind of the minimum for social applications with really huge appeal. It's hard to get an idea of if it's compelling or not (or how far away it is, what needs to be improved, etc) without trying it though.