matt_m

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.

Go is also statically typed while Erlang/Clojure are dynamically typed. That seems like another pretty significant difference aside from the syntax.

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).

It wasn't obvious to me either, but apparently vgo translates that into the appropriate git tag, it's not actually a separate directory.

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).

Sure, I think I can explain some of what people might see in it. Obviously its strengths/weaknesses will depend on what language you compare it to, the article mentioned Java so I'll use that.

1) Value types - in Java if you want an array of objects of a non-primitive type, each one will be individually heap allocated (with some extra per-object overhead) and stored as an array of pointers (may change in Java 10). Go allows objects to be linear in memory with no overhead.

2) Slices everywhere - in Go slices are the default list representation. This allows any API that takes a list of objects to be passed a range of a bigger list, without copying/allocating.

3) Low-latency garbage collector - I believe Go has one of the lowest latency garbage collectors in common use (sub-1ms pauses). I realize Java has several options, but I think Go's is lower latency than all but some commercial/exotic ones like Zing. This is not saying the GC is better all around, just on latency. It's also relatively easy to minimize allocations in Go due to value types.

4) Low-overhead concurrency - lightweight tasks with no blocking/non-blocking dichotomy in APIs. But threads can scale up a lot, so this might not be a big benefit depending on the application.

5) Interior pointers - you can lay out structures linearly, and still use interior pointers. Also, you can use them as interfaces without allocating any 'boxed' objects.

There's probably more, but these are the things that come to mind right now. Looking back on this list, all of them are performance related. So if an application isn't performance sensitive in any of these ways I guess it would be understandable that someone might not see much in it, compared to a language with a higher learning curve but a lot of conveniences like Kotlin. Things like capitalization don't seem that big an issue though... maybe because Go is a simple language the tooling is already pretty good, and you can easily rename to upper/lower case in an IDE like GoLand.

For people unfamiliar with Go and want to see something more than hello world, I think an interesting project to look at is https://github.com/fogleman/pt. It's not enormous but not trivial either and makes use of interfaces, goroutines etc. The author's other projects are great too.

Yeah that seems like that might be the best option right now, and it doesn't look like it will be too expensive either. What I probably would like more is the reverse, a Metal wrapper for Vulkan, since it seems so much easier to get started with Metal. Too bad Metal is a Swift/Obj-C API so it's not straightforward how to make it cross platform.

I don't know how much bad faith I want to assume on Apple's part, since there are probably some legitimate technical reasons why they don't want to support a lower level API (and they came out with Metal first). Vulkan is such a pain to use anyway that it's probably mostly used by engine developers who generally don't have a problem supporting multiple APIs like Metal / DirectX etc.

But at the very least, it would be nice if they upgraded their OpenGL version, since they already support that and it's only them holding back some of the newer features.

Maybe I could have explained this better since it's getting downvoted. Right now the two big modern graphics APIs are Metal (iOS / Mac) and Vulkan (Win / Linux / Android). These aren't the only ones, there are more for game consoles, UWP apps, etc, but they are arguably the most important ones.

Metal and Vulkan are not at the same level of abstraction. If you look up the code needed to draw a triangle on the screen (maybe the most basic graphics task), it is much, much more long and difficult to do it in Vulkan than Metal. Vulkan is a lower-level API. It gives engine developers more flexibility, at the cost of making basic things time-consuming and complicated.

OpenGL was the previous cross platform API. WebGL is almost identical to OpenGL. OpenGL still runs on Mac / iOS, but Apple has stopped supporting newer versions. The newer versions of OpenGL have closed the gap some with Vulkan and Metal (it won't catch up entirely, but it added some important features like compute shaders and it's easier to use it efficiently). OpenGL is still easier to use than Vulkan. The problem is the newer versions are not cross-platform, since Apple wants to focus on Metal.

Apple does not want to support Vulkan. Metal came out before Vulkan did, and it is a higher-level API. It's arguable if Apple should support it or not, but that's how it is. Microsoft also wants to focus on DirectX 12 (their API).

I was making the argument that a higher level API, Metal-style, would be a good base for the new web standard. Metal couldn't be used directly, at the very least it would have to be changed from Swift/Obj-C. But the idea of roughly basing it on Metal as mentioned in the article doesn't seem unreasonable, even Vulkan was based on a previous AMD technology called Mantle.

A low-level standard like Vulkan is hard to use directly, its adoption will depend mostly on people using frameworks / engines that use Vulkan. It's possible that due to its low-level nature there would be some performance advantage, although games using Metal also seem to get good performance on iOS. The disadvantage of Vulkan is that it is much harder to use than WebGL.

A fair amount of the WebGL content is not web specific. It is possible to write OpenGL content and compile it for desktop / mobile and the web. The most popular game engines, Unity and Unreal, both support compiling to the web and desktop from the same codebase.

In my view, there is no good replacement for OpenGL, now that new versions are not cross platform. Vulkan is much more work and does not work on Apple platforms, while Metal is easier but only works on Apple platforms. If they could provide a standard that is both easy and cross platform (by providing a C API library in addition to the web standard), it would provide the best of both worlds. The main downside is that it might leave some performance on the table compared to a low level API, and it would be yet another standard (which is why it would be important to provide a native library too, so developers have the choice of coding to only one API).

Well, as a small developer I'd love to see a higher-level, easier-to-use API (than Vulkan) that can be used as a modern, cross platform replacement for OpenGL. If it could be used both in a browser and standalone even better. If it was available outside of a browser (even as a Vulkan/Metal wrapper), I think it could become a no-brainer replacement for where OpenGL ES is used today.

I understand that engine developers can get some (small?) percent improvement from an ultra-low-level API that exposes more platform specific details. But they almost always support multiple APIs natively, and already use the low level ones where available. There may be a small performance benefit (over a higher level API) in the browser, but I don't think the browser is a likely target for ultra heavyweight apps / games, that usually are multi-GB downloads anyway, in the near future. And keep in mind that if smaller software sticks with WebGL because of API complexity, that might be a big performance loss for the user.

But a higher level API would have great benefits everywhere! Right now the only real cross-platform graphics API is OpenGL ES 3.0, which is becoming more and more obsolete, with little sign of the situation changing. No compute shaders, no AZDO, etc. Any move beyond that feature set now requires multiple APIs, shaders etc. And the easiest way for a small developer to get those features is still to skip Vulkan and to stick with GL ES 3.1+ on Win/Linux/Android and choose Metal on Mac/iOS. Of course on the web for those features there are no options at all.

I think if a new API was available that was easy to use and truly cross platform (including web), it would be the obvious first API to implement for all new graphics software. And this would be a much larger benefit than an unknown performance improvement that is accessible mostly to engine developers.

This is a common sentiment. How far does this concept go though? If a neighborhood gets too expensive, you can move without much trouble. The whole city and commuting area gets too expensive? Move again, but now find new company/personal relationships. What about all cities for <industry> get too expensive. Change careers maybe?

At the very least the supply of housing should expand until it's proportionate to the amount of office space (jobs) in the area (although apparently office space is more lucrative for municipalities than housing, so we get more of it).

It isn't unique to California either, most cities in the US with good job markets (NYC, Boston, Washington DC, LA, etc) have seen housing prices shoot up.

I'm not sure it's true that building more housing has no effect on prices, Seattle has had a lot more housing built and apparently they haven't had quite as extreme price increases, although they also have a thriving tech industry. Raleigh/Durham has been growing incredibly fast but adding a lot of supply too. And more people moving in surely must lower the price at least where they are moving from, so if several places build prices can't go up everywhere.

It might be late / politically difficult to address the issue in California, but the escalation of housing costs is such a common problem that the solution can't always be "move away from <job center>".

Of course how to manage growth without excessively burdening existing residents or communities is another matter, but hopefully not impossible? Development doesn't have to go everywhere, but surely it should go somewhere? At least around transit hubs would make sense.

Well, I'm not sure a technically impressive hackathon project is a plus past a certain point.

Not everyone follows the rules of the hackathon and works only during the time period. I was on a team that was a finalist at one of the startup festivals and won a few thousand dollars. Talking with the prize sponsor afterwards, they said something along the lines of "you don't have to pretend you did this all at the hackathon, I know how these things work". When they realized that we did, I think they were disappointed!

It worked out for us that time, but in most hackathons they don't have time to vet all the projects thoroughly, and if you do too much there will be a strong suspicion that you are cheating and just using it as a pseudo startup pitch and that can be held against you.

If you want to win, I think the best strategy for productive teams is to do more than one project since it's hard to know what any particular judge will like.

Anyway, to answer the question, the most impressive was probably a UI layout app (Mac) that synced the layout in real time with native iOS and Android apps using native widgets (this was before react native was popular). Where it was only a 24 hour hackathon and I ended up doing all 3 apps from scratch. I'm still pleased about getting horizontal and vertical snap alignment in! I'm sure the judges (reasonably) thought it was not from scratch but it can be fun to push once in a while, and people you hack with will know you did it.

It's best not to take it too seriously though. Rather than be impressive, it's probably better to be creative and do lots of stuff (and have fun too!).

IMO Cardboard / GearVR is so different from the Vive / Rift+Touch right now that it is more useful to look at them entirely separately even though they are both technically "VR".

Cardboard and GearVR are relatively convenient and inexpensive but do not seem to be a very compelling product, since it is inconvenient compared to a monitor and frequently causes motion sickness, while offering few advantages. I have both and barely use them.

Vive and Rift+Touch are incredibly expensive and inconvenient (cumbersome set up, tethered, not portable). But a lot of the content basically never causes motion sickness (even for sensitive people). I think there is at least the beginning of a compelling product since I've had a chance to let a variety of non-technical people use it. Even if they're reluctant to try it at first, there is usually one of the programs they enjoy and keep using for quite a while.

I don't want to oversell the Vive - there are a lot of problems starting with the low resolution. But the problems with the high end systems will inevitably improve over the next few years - there will be more content, the resolution will improve, the cost will decrease, it will be more mobile etc. Also, I'd expect the Vive to be a relatively low capability device in the future - there's a lot of tech being shown off these days with eye / facial expression / body tracking that hasn't been integrated into a mass market product yet. It will be interesting to see what applications benefit from those.

The current low-capability systems seem like a dead end though, they've been available for a while and don't seem to have taken the world by storm, and once more capable mobile systems come out that will be the end of that UI paradigm. Simple things like reaching out and picking something up or moving it aren't possible, for interactive content the differences are really fundamental.

As far as the comfort issue goes, the weight distribution can be improved a lot without waiting for next-gen display technologies. PlayStation is the best this generation with a rigid band the headset hangs down from, and LGs upcoming one can flip up without taking it off all the way. Certainly putting all the weight on the face is a bad idea though and harder to avoid for phone-based systems.

That's a good point, for example when many individual app developers were being sued / threatened for the use of in-app purchases, it could be argued that the root of the problem is that something like in-app purchases is not an idea that otherwise wouldn't see investment due to the lack of a profit motive, and that it shouldn't be covered by the patent system in the first place.

For the idea that patent trolls add liquidity to the invention marketplace, I'm under the impression that the cost of acquiring the patent in question is often only a minor component of the operation, and the major cost is litigating it. Which seems to suggest that the primary economic effect is something else (what that is I'm not sure).

I think part of the problem with NPEs is that in practice there is a natural disincentive for large companies to sue over (possibly) frivolous patents, since they generally each have large patent arsenals and can countersue causing a loss to both companies. So there is an incentive to have some degree of restraint except in particularly egregious cases, and for total patent wars not to go on forever. NPEs obviously don't have this incentive, and it's not clear to me how a change in patent law could effectively replicate it.

LuaJIT (of which DynASM is a component) is a JIT compiler for Lua (a dynamic language), which despite being basically a one-man project was beating contemporary Javascript compilers on performance and even the Dalvik Java compiler on Android (making it the fastest JIT compiler in existence for a dynamic language). Also, it targets multiple platforms (x86, x64, ARM, PPC, MIPS). It's been in maintenance mode for a while I think.

A couple interesting links about the internals:

http://lua-users.org/lists/lua-l/2009-11/msg00089.html

https://news.ycombinator.com/item?id=2617628

The Microsoft Sculpt Ergonomic mouse is semi-vertical (this might depend on how you hold it) and tracks better than the Evoluent mouse I was using before, although the ergonomics are probably not as good. The build quality is also better IMO than the Anker / Sharkk vertical mice popular on Amazon.

Haven't tried the DXT mouse mentioned in the other comment.

Rather than just hoping for critical mass for one candidate, it would be nice to switch to something like ranked-choice voting (it's used at the local level already in some places like San Francisco I think). It's hard to advocate voting for 3rd parties with our current system, where causing the least-preferred candidate to win is by far the most likely outcome.

Around a decade ago when I was an Apple intern (pre-iPhone) we got to go to a Q&A session with Steve Jobs. One of the questions was something like "What other products do you think are badly designed / could be improved?" and I remember him mentioning two products, phones and cars specifically. I don't really have any idea what Apple plans to do there either, but at least the interest there probably isn't new...

I imagine it depends where the computer is used - users that mostly use it on a desk where they plug / unplug it but don't move it around a lot while plugged in probably don't have problems. The cords always seem to fail if they are used a lot on a couch / in bed etc, and since the portion of the cord that fails is not easily replaceable there's not much choice but to buy a new one for nearly $100.

A long time ago, before the MagSafe cables, name brand third-party Mac laptop chargers were available that you could use however you want without fraying. I had one from Macallay. The reason why it never had any issues when using it the same way Apple chargers failed was obvious: the cable where it connected to the computer was a lot thicker.

As far as I know, there's no legal third party MagSafe cables, and the knock off ones copy Apple's design anyway and have no advantages. I've learned to just use it on a desk most of the time when plugged in, since it's a nuisance to deal with failing power cables. But for me, that's a pretty big trade off in order to gain a more aesthetically pleasing cord thickness.

I suppose it's debatable what sort of usage counts as 'abuse' or not, but you can be assured that the Apple chargers will fail in the exact same circumstances that other chargers will not. It's probably my single biggest issue with their hardware, especially since they prevent any alternatives from being available.

There's a lot of negativity around recurring payments but I'm excited about this model both as a developer and a consumer particularly on iPad. There's been a race to the bottom in pricing in mobile app stores, where a one-time payment equivalent to a cup of coffee can be seen as too expensive for an app costing tens of thousands of dollars (or more) in engineer time to make / support. Maybe as a result of this there's no shortage of micropayment or advertising based mobile games but the productivity space is not very competitive with Mac/PC where people don't blink at paying 10x that cost up front.

If this can establish a middle ground where more app categories can find a sustainable business model including long term support and updates that could be very interesting, especially now that many apps might want to include cloud-based features where committing to support forever in exchange for a one-time payment might be a risky proposition.

The important costs though for the current wave of VR are hundreds of millions of dollars for OLED display manufacturing lines, and an additional many millions of dollars of engineer time from Nvidia / AMD / HTC etc for custom drivers, low persistence hardware etc. It's very, very, likely that previous $80,000 or even $200,000 systems are not up to par with current mass-market hardware regarding key metrics relevant to motion-sickness, or even that the military bidding process would even specify those metrics considering that their importance was only discovered recently through user testing on hardware that was not previously available.

One other interesting thing to note (at least on the HTC Vive) is the majority of the content for the platform is focused on standing / walking with motion in real life matching 1-1 with motion in VR. Which both stops a major source of motion sickness and rules out entire categories of software like flight simulators, which seems to be his entire work history.

Sure, I agree Java isn't going anywhere, I just meant it might grow some at Java's expense since it has some of the same strengths (and while the ecosystem might not be up there with Java it's surely competitive with some of the other languages used for backend development).

C# works a little differently from C/C++ in that stack vs heap allocation is decided at the type level (using a 'struct' or 'class' keyword when defining the type). So you can't easily have one object have a reference to an interior Point in a Point[] array, since any Point instance variable will just be copied by-value and not be a reference. A Point in an array can be passed by reference into a function using the 'ref' keyword though, in which case I'd expect the GC to keep the whole array around until the function returns? (It seems hypothetically possible to optimize but kind of a niche case). If you need to, you can also actually use raw C pointers with an 'unsafe' keyword, that's outside of the GC though (useful for working with C libraries).

Might be worth considering C# here too. The open-source cross platform tooling is new and still immature, but it's getting serious resources lately, with new language features (including more null safety) coming, cross platform IDE from Jetbrains in development, Mac / Windows / Linux / Android / iOS support, good concurrency features for server side development, JIT and AOT compilers + runtime, development mostly on github etc. They seem to be serious about making a first class cross platform language, I wouldn't be surprised if it displaces Java some in a few years.

The biggest thing compared to C and C++ (or even C# and Go) is probably the lack of user-defined value types. So if you want to create an array of Point2D objects, in Java it will be an array of pointers to heap-allocated objects (each with additional per-object overhead), which is really bad for cache misses, memory consumption, GC pressure etc. C# is a pretty similar language that is popular for game development (with Unity) but unlike Java it supports value types.

I have a Vive (Pre) and tested it on some older equipment. Less demanding apps like Tilt Brush will even work on older cards like the 750 Ti, but >50% of the available demos so far won't run at that level. A 950 is much faster and not too far from a 680 though, and Valve is working on lowering the performance requirements and made their portal demo work at 90fps at that level. They are going to be giving a talk at GDC in a couple weeks about their rendering technology to dynamically adjust quality settings to maintain FPS on lower cards, which they will be integrating into Unity so most developers will have access to it.

Anyway, I think it would probably be OK to order it now and expect to have access to a reasonable percent of the content, and then wait a few months to upgrade the GPU when the next gen from AMD and Nvidia comes out.