sn1de

I agree with your more nuanced take on the golang community's position. I still think that a fully realized framework is, in general, a better starting point for the vast majority of projects. Part of the problem is that such frameworks are few and far between. I'll stick to the Ruby community: I know developers I respect who really like Sinatra, which would be more akin to a microframework. It is their go to starting point, but when I go to work on their projects I very quickly find myself straying out of Sinatra's capabilities into things that are fully baked into Rails. I then have to spend time pulling that capability into Sinatra, which is not how I like to spend my time as an application developer. There are many frameworks that are positioned as 'elegant' or 'focused' when they are simply incomplete in the face of real world development and teams end up having to either cobble together disparate micro-framework or rebuild basic capabilities to get to a fully realized app. I would argue that is not time well spent and that everyone thinks they are super good at creating solid, performant, extensible, well documented code, but they are not (statistically speaking) and by then it is too late and others have to live with their junk for years, or worse yet they all bail because now they know hot-framework-x and board the recruiter train to their next salary bump.

I don't know the php ecosystem well at all. I just didn't want to come across as 'Rails is the only one true way'. Lots of php folks seem to love it, and it derives a lot from Rails, so I thought it was a fairly safe shout out. But, it is HN after all, so no opinion can be put forth without and equal and opposite negative reaction.

Yes, the state of the industry is a hot mess, but I'm not sure this article rings true. Failing to leverage good frameworks is as big a problem as over using the bad ones. I would point to Rails as an example of an appropriate framework (and Laravel if PHP is your jam). The trouble is so many others are bad, incomplete or defunct, but I don't think the answer is the golang mantra of 'we don't need no stinking frameworks'. Seeing mediocre developers reinvent the wheel, slowly and badly, is super painful and wastes time and money. If you hate the frameworks available to you then perhaps you should consider finding a better ecosystem. Relax your bias and follow the happy developers, wherever that may lead.

The x86 hardware and the Linux OS both had to make the jump to 64 bit. Sun was still able to make hay in the period where Linux was well established because 32 bit memory restrictions kept if from being a viable option for a lot of higher end computing needs. It was inevitable that Linux would eventually make the migration to 64 bit once the hardware was there, but Sun got there first on both the hardware and software fronts. Why Sun didn't react more radically when 64 bit Lintel was able to go head to head with Sun's precious 'enterprise' solutions is unknown to me. Maybe they were just in mass denial? Maybe they thought the technical hight priests within their organization would manifest new technical advantages? Maybe they just knew that if they dropped their pricing to address the new price/performance reality that their company was no longer economically viable? There was a lot of denial about Linux at the time, and there were plenty of legitimate reasons to question whether or not Linux could really make the leap to compete head to head with the leading commercial Unix offerings. Meanwhile, major efforts were being made by the likes of IBM and, ironically, Oracle, to contribute to efforts to make Linux a 'no compromise' commercial offering. Remember that companies like IBM had watched their own Unix offerings suffer from Solaris on the high end and Linux on the low end. The smart ones realized that Linux could be the answer to the hard sell they were running into with their own Unix and put engineering efforts towards making that happen. I'm not saying Linux wouldn't have gotten there without them, but there was a strategic shift that happened to accelerate the technical ascension of Linux, and that also caught Sun off guard. I suspect they had looked at the historical trajectory of Linux and over estimated how long it would take Linux to 'catch up' to Solaris. Linux went 'hockey stick' on Sun.

Agreed. In my mind, the M1 Mac I'm typing this on is a direct descendent of the NeXT workstation that launched while I was still a student with no hope of ever owning. As much as I love the progress, it does make me wonder where/how the next true breakthrough will come from, or will we just continue to evolve what we have for another few decades?

They were already doomed at that point. I was involved in several major purchase decisions during that period and Sun were totally out of touch. If they were quoting hardware that had an x86 equivalent, then they were overpriced. If it was something that didn't have an x86 equivalent, like they had for a while with 64 bit, the prices were atrocious. Then Lintel moved to 64 bit and it was all over. The price/performance equation was broken, but Sun, for whatever reason, kept on like nothing had happened. I, and I'm sure many others, tried to show them that they were uncompetitive, but you were dealing with reps working from a price sheet and citing the same old mantra that Sun was inherently superior. For years when I would tell peers that the Sun equipment was just throwing away money they wouldn't believe me because they hadn't done the benchmarking. Really, if people did proper benchmarking and didn't just 'buy what they know' without questioning, it all would have unwound even more quickly. They certainly had some good tech, and were not wrong about the advantages of containerization, which came full circle with linux containerization and docker, but IBM mainframes had similar virtualization capabilities in place long before Solaris zones, so it wasn't something that was a game changer. Ironically, it worked against them because even though they were right, it was seen by some as Sun touting their way of doing it because they didn't have a viable solution for the prevailing VM direction of hardware virtualization. Basically, they began by offering the best price/performance and innovation, but then died trying to be a 'premium provider' without the goods to back it up, and market forces then do what market forces do.

And instead we should all use ???

Hello?

If there is a business/domain need for this capability most organizations will go with some kind on content management solution (CMS) of which there are myriad solutions. Git would be considered bare bones and unintuitive compared with the best of these tools.

It competes with anyone selling point of sale hardware. I think Square falls into that camp, no? I wouldn't want to be in that space right now. I don't see how this doesn't usurp a big chunk of their market since it isn't even a decision between buy this or buy that, but buy that or just use the thing already in my pocket.

As in 'slight of hand' employed by a magician. Where someone makes an obvious movement to distract from something they don't want you to see. In this case, the assertion is that the Metaverse is more hype than reality. A shiny object, or concept, to create a plausible narrative that bridges Facebook into a future where they once again dominate, while distracting from the possibility that their current position is in decline with no tangible mitigation plan.

lol'd at this one. i have a new tv, I have gone to youtube several times now to figure stuff out, and I am well versed in a/v.

20+ years of web site ecommerce development experience and what I see is that consistently the designers and the managers and/or product owners (who have the final say and must be suitably impressed) have no access to, or don't bother to consume or understand the site metrics and in many cases don't even have a rudimentary understanding how how their site works (or doesn't work). I've been in so many meetings where the group was ready and willing to kill a feature, or a link or a button and I've had to bring up hard metrics to keep them from killing something that not only people used, but converted more often with a bigger cart. And these are ecommerce sites, so I can only suppose that it is even more so with any site where cold hard cash is not on the line. The trend towards hiding things just to make the design look clean is ignorant and lazy. UX is hard. It should be driven by metrics and validated by observing real user behavior. Anyone who doesn't do that is being vastly overpaid and inevitably eroding the user experience. Nobody should ever have to hover randomly around a screen to hunt for controls, but I see it every single day, and now even on former bastions of usability like core Mac interfaces. How does this stuff get through usability testing? A: It was probably never done, or if it was the aforementioned decision makers never gave it a first let along a second look. Best advice I can give is to never, ever, do a wholesale site redesign when conversion counts. Always incremental, always iterative, always driven by metrics and true usability labs. If someone balks at doing any of this, they shouldn't be in the business, get rid of them or ask for another designer/team.

Karma police Arrest this man He talks in maths He buzzes like a fridge He's like a detuned radio

I went through a cycle of: study ruby -> start using rails -> seems magical -> realize you don't know ruby yet -> study more -> rails no longer feels magical. I suspect this is typical given that there is lot more to ruby than appears on the surface and rails heavily leverages the metaprogramming capabilities.

Baffling that this wasn't a day one feature. Doubly baffling that it now launches on Enterprise only with no guidance on if or when it will be generally available. Never an explanation why this couldn't have been there all along. You have it with the repos already. It almost seems like you would have to go out of your way not to have this baked in from day one. I'm a long term fan, but c'mon github, you're better than this.