beetwenty

Std::string half of all allocations in the Chrome browser process (2014) [0]

The key difference is that web browsers support a highly arbitrary and mutable dataset. A game engine's assets exist in a mostly-static space. The things that are allocated at runtime are things that should have a known maximum, because going over that maximum will start to overrun latency targets. Many assets are streamed, but still hit a certain size and bandwidth budget, and so are still "basically static" - some degree of compilation and configuration at runtime always takes place for rendering features. The genuinely mutable part of game state while playing is in a comparatively confined space, and that allows a lot to be pushed to build time, where it's easier to validate and to maintain.

The features that change this picture are editors and arbitrary data imports. Web browsers are all about these two things. When you click a link the document may load thousands of gigantic images, and I might try to copy-paste the entire contents of Wikipedia into a text box. The engineering requirements are much broader as a consequence, and there are more rationales to need genuine "black box" interfaces supporting a complex protocol, as opposed to a static "calling function switches on a specified enum" approach, which is sufficient for almost every dynamic behavior encountered in game engines.

[0] https://news.ycombinator.com/item?id=8704318

That's a data synchronization error across multiple related pieces of data, which isn't the same as a POD container like a hashtable corrupting itself.

The standard hammer you would apply to enforce the synchronization in all cases is relational integrity, which is too expensive for a game's runtime environment. You don't always want to synchronize everything all of the time if you want to hit a high framerate target, and a lot of performance features boil down to relaxations on when synchronization occurs. Much of the detailed design in writing a game main loop is in dealing with the many consequences of supporting that.

That's why their recommendations on errors also refer to the earlier build process and Lua integration; by the time the data hits the inner loops of the engine, there shouldn't be a case where it's invalid, because if it is, then you can't have the optimized version either.

On the one hand, this is a predictable outcome if you are trying to shepherd a large codebase through a fast-moving language. Idiomatic Python 1.6 looks dramatically different to idiomatic Python 3.x.

On the other, Rust isn't the language I would want to write lots and lots of code in either. There are a few projects and organizations where it makes sense to do so(namely web browsers, databases, and other kinds of "deep backend, large surface area" types of projects), but most of the things it does well also act as a hindrance to feature development, compared with an idiomatic Java, C# or Go equivalent.

I found my way out.

The thing I had to do is to find some themes that I am idealistic about and stick to those. The project is just a mode of exploring the theme, which means that each project and my skillset grows as needed to accommodate. The projects you are describing are completely non-thematic and are just bundles of features, so of course there's no structure to them, no reason to keep going and seeing what's next. And you are probably not money-and-sales-motivated, which is the thing that drives a lot of obvious business ventures.

The first step in finding the theme is in "knowing thyself", of course - strengths, weaknesses, inclinations. Write and rewrite the set of things about yourself that is maximally coherent and self-reinforcing. Then drive down that road as far as you can go: What types of projects does that support? Gradually you'll hit on a common theme, and then you can really start building.

Another way to force this along is this art advice: "Draw the same thing every day." This is a rather crushing challenge to take on, for no matter the subject matter, you'll tire of it, but it quickly brings out your inclinations and therefore the themes you want to work with.

I'm working with Lua right now(gopherlua) as a scripting option for real-time gaming. I've done similar things to your story in the past with trying to make Lua the host for everything and I'm well aware of the downsides, but I have a requirement of maintaining readable, compatible source(as in PICO-8's model) - and Lua is excellent at that, as are other dynamic languages, to the point where it's hard to consider anything else unless I build and maintain the entire implementation. So my mitigation strategy is to do everything possible to make the Lua code remain in the glue code space, which means that I have to add a lot of libaries.

I'm also planning to add support for tl, which should make things easier on the in-the-large engineering side of things - something dynamic languages are also pretty awful at.

It's basically true of anything using physics. There are very good pinball simulations, and being reliable digital games they are actually a better, more fair competitive venue, but people who really play pinball still crave the real game because of all the analog parts of it, the nuance of pressing your weight down on the table and how that changes across different games, and how you adjust your play to the specific conditions as things wear down.

Or, in another word, "disposability". We have a lot of systems that aren't repairable, don't get debugged, don't have things fixed mid-flight.

And...it works, with respect to most existing challenges. Restarting and replacing is easy to scale up and produces clear interface boundaries.

One way in which it doesn't work, and which we still fail, is security. Security doesn't appear in most systems as a legible crash or a data loss or corruption, but as an intangible loss of trust, loss of identity, of privacy, of service quality. We don't know who ultimately uses the data we create, and the business response generally is, "why should you care?" The premise of so many of them, ever since we became highly connected, is to find profitable ways of ignoring and taking risks with security and to foster platforms that unilaterally determine one's identity and privileges, ensuring them a position as ultimate gatekeepers.

D3 does the Right Thing with respect to dataviz.

That means: it's conceptually overloaded for doing quick-and-dirty conventional charts, where you just want to plug in a few parameters and have it "just work" - but excellent once you need to customize and make it work with your specific requirements.

That it has the concepts, and a clear notion of them, is the critical difference. Most libraries, most of the time, don't add new concepts, they just have a premade black box of features and functions. Sometimes you want a premade black box, but often you want to open up the box shortly afterwards, and that creates the inevitable trend towards either remaking it as your own box, or being one of hundreds of people who gradually grow it into a monstrosity that does everything.

But a library that is concept-focused doesn't have to get that much bigger: it's just another kind of interface, like a programming language or an operating system, and that puts it on a more sustainable track.

A representative for the union that represents more than 19,000 academic workers across the University of California system said she was surprised by the university's decision.

"We are shocked by UC's callousness, and by the violence that so many protesters experienced as they peacefully made the case for a cost of living increase," said Kavitha Iyengar, president of UAW Local 2865, in a statement. "Instead of firing TAs who are standing up for a decent standard of living for themselves, UC must sit down at the bargaining table and negotiate a cost of living increase."

Last week, the university filed an unfair labor practice charge against the union, claiming the union has failed to stop the wildcat strike by the graduate students as it is required to do by the collective bargaining agreement.

The union responded by filing its own unfair labor practice charge, alleging the university has refused to meet with the union to negotiate a cost of living adjustment.

Direct from the article. Care to back up your statement?

The tradeoff in goto-vs-exception is that a goto needs an explicit label, while an exception allows the destination to be unnamed, constrained only by the callstack at the site where it's raised.

That makes exceptions fall more towards the "easy-to-write, hard-to-read" side of things; implied side-effects make your code slim in the present, treacherous as combinatorial elements increase. With error codes you pay a linear cost for every error, which implicitly discourages letting things get out of hand, but adds a hard restriction on flow. With goto, because so little is assumed, there are costs both ways: boilerplate to specify the destination, and unconstrained possibilities for flow.

Jumping backwards is the primary sin associated with goto, since it immediately makes the code's past and future behaviors interdependent. There are definitely cases where exceptions feel necessary, but I believe most uses could be replaced with a "only jump forward" restricted goto.

That isn't a "normative" statement about better, but a "positive" statement about a trade-off of expressive power versus rigor. A bit of mathematical intuition suggests that formally asynchronous approaches tend to be less powerful and hence more rigorous. But if your spec is still in the prototype phase, taking on a lot of expressiveness and permission with respect to your domain model is desirable because it gets you an end-to-end solution sooner.

What is good is not "on time" or "robust", but "on time and robust". Necessary and sufficients.

When I see articles with so many various facts assembled together, I have to remind myself that the author cannot possibly be an expert in all of them, and so the story is just that - a story.

Which doesn't change the fact that something needs to be done, or that many of the predictions will come to pass, just, the full story is never going to work out quite how anyone expects. And that's enough to have some hope.

This is probably only true if you're thinking of the complexity in terms of board-game style complexity, with characters and items and abilities that you can enumerate in a list. That's the type of thing that digital computers are pretty good at doing and analog systems aren't, so in our digitally-soaked culture we tend to appreciate it more and associate it with being "more complex". But it also hit a saturation point in the 90's, right around the time SMW came out in fact - there are plenty of early 90's PC wargames and RPGs that are just baffling to play because they model the playspace in a way that makes for spreadsheet UI.

Detailed physics and AI, on the other hand, is a thing that is largely beyond the ability of the SNES platform, and that's something that started to pick up along with 3D gaming. We don't greatly appreciate these things in video games because we can pretty easily play with blocks and balls or find live opponents in the real world, but it's a realm that still has a lot of untapped potential.

A lot of the facets of leadership are created from the small details of how the organization "automates" itself.

Consider meeting planning, for example. How frequent meetings are, how long they are, how many people are involved, what the meeting venue is, and how the agenda and format is set.

There are all sorts of knobs to turn just in saying "what a meeting should look like" that will impact the flow of communication, and different teams in the same organization will tend to have different meeting styles, but at a high level, the planning has to include considerations around how to allow different teams to interact effectively, since those are the bottlenecks where the information tends to get siloed.

And then you can turn to hiring, assignments, training and promotions and there's a similar kind of thing, where the same person in a slightly different role may be hugely more or less effective, and defining the problem differently changes the kinds of assignments and skills needed. Who creates those definitions, and how? It's not necessarily the manager those employees report to that's creating them.

In fact, there's a whole cascade of effects that come from the macro situation that end up translating into differently defined roles: different legal and regulatory requirements, education and training standards, minimum wages, healthcare coverage, labor organization efforts, etc. The same people in a different country may be happier and more effective.

So, while the manager is the biggest factor in the equation, it's not all on them - it can't be. Some ways of doing business and types of company culture will work in some scenarios and others will not, and the marketplace has an evolutionary tendency to just make random permutations of management style until it finds one that doesn't die, even if it creates a toxic environment. In that light, "effective" management is a highly relative thing and can be encouraged or discouraged by the broader shape of the economy.

The sense I get from all of it is that there's a phase shift in technological progress occurring, not dissimilar to the 1970's one where we ceased seeing the bulk of disruptive developments occurring in vehicles and energy, and started seeing them in IT fields. That initial boom produced a lot of new product categories, and then successive decades saw a lot of consolidation and transformation away from nuts and bolts and simple efficiencies towards services and IP holdings and consumer marketing. And we know the nature of that market very well today since everyone present has breathed in it for most or all of our lives at this point.

But the nature of the next market is, of course, much harder to glimpse. Like looking into pier glass, it takes effort to get a fragmented view of things. It's not as easy as Thiel's view: AI and surveillance, for example is more broadly authoritarian than it is any specific ideology. And infrastructure often leapfrogs stages in the developing world, and that can be true of a developed country like the U.S. too.

There's plenty of good work being done quietly in the current market. The word I'd pay the most attention to is sustainability, though. It's been more-or-less entirely a marketing term for decades, never delivering on the promise, but then, often it takes a while for the products to catch up to the marketing.

With respect to their core CPU business, they were executing on a monopoly playbook since the start of the decade - 4 core desktops and 5% generational improvements on the same architecture, every generation - which made them organizationally unfit to stay competitive. When the Ryzen chips first launched they quickly moved to punch up the core counts to keep pace, but were still waiting on their 10nm process to come through, so they ran out of breathing room really quickly. For the past year it's just been "run hotter and engage in FUD", and now that AMD has got onto 7nm process there's really no comparison to be made.

Could they have seen it coming? Absolutely, and they could have had a new architecture ready earlier or adjusted their process plans to de-risk, but again, multiple years of uncontested dominance in their main business tends to make things that aren't next quarter top-line a lower priority. And I think that really is at the heart of the issue with their projects failing so frequently. Intel's pursued anti-competitive practices for decades, and when it works, they coast along without urgency, letting marketing call the shots, and when it doesn't they use their economic moat to rush a solution.

But this time, with everything running late, Intel is going to face several quarters ahead without having a real response on the CPU front. They are not going anywhere, though. Their foundry channel is needed to meet global demand for new chips - a good deal will still find buyers. They still have plenty of existing agreements to work with, and can negotiate their way through a lean patch. And they have their new GPU stuff coming soon which should hopefully give them a piece of a different market. There will be plenty of stress to re-org along the way, though, so Intel could come out of this looking very different.

The thing that has really kept me from getting behind updates to the C++ universe is the lack of progress on improving the state of build tooling. It is miserably underengineered for modern, dependency-heavy environments. C++20 does introduce modules, which is a good push towards correcting the problem, but I'm still going to be "wait and see" on whether the actual implementation pans out.

There are a few rough edges in old BASICs(and they have been smoothed out in pretty much every one that's shipped since 1990 or so) but the practical truth is, to implement most code in a readable form, you don't need a great deal of expressiveness, syntactical sugar, or structured flow control, but you do need a few common data types and features to work with them, and even vintage BASIC does that much.

This is what people mean when they say that languages haven't progressed that much. There are places where they have(e.g. dynamic memory allocation features really do matter to large-enough, featureful-enough programs) but almost all the features can be dispensed with for the base case of solving one problem well. The tooling and ecosystem matter a great deal more since they make the difference between having a finished solution in hand and having to fight to get something built and deployed. I/O and protocol compatibility are major sticking points everywhere.

"Streetcar suburb" is correct. The Outer Sunset formed around the old "Carville" site, and the district's development was mostly complete by the '50s. But the blocks of row houses on a grid are such an old planning concept that it's almost unrecognizable when compared with late-20th century suburbs. The hills are a bit too steep and the streets a bit too busy for a young child to safely bike around or play in. On the other hand, skaters enjoy the slopes and curb cuts and often film there.

That's the joke - Atherton is the town of the tech billionaires.

That's correct. State is handled by the user, which is great for some things(dynamic quantities of elements - no caching layers, just feed it a for loop) and awful for others(maintaining pre-committed state for e.g. a configuration panel with checkboxes, text fields, etc.)

Ultimately the ground truth in both instances is that you have potentially many data models that the UI has to aggregate, and the source model, layout, display properties and hitboxes of elements are usually but not totally related and can change due to many kinds of events. Any formal structure you might come up with is bound to run into exceptions. As a result I tend to have this policy:

* I don't trust the framework

* But I leverage the framework to produce early results, and both immediate and retained modes offer ways of doing that

* I expect long-term maintenance to involve a customized framework design regardless

I've heard it compared to Walmart in the USA, and having visited both chains, I can see the resemblance, even if it's not obvious at the surface. Walmart's layouts are "big box", designed for automobile users who will carry their purchases to the parking lot. Donki's layouts are compact, for people who will take their purchases(most of them, anyway) onto public transit. Everything else about both stores is built around the premise of a broad selection of low-end goods at low prices.

They are not beautiful, but I am fascinated by these chains as a phenomenon, nonetheless.

It isn't literally a continuous loop, not in all locations at least. The ones I visited when I was touring last year were playing a more typical department store tracklist, but I did hear the theme at least once.

My observation from having tested the three most common isomorphic systems with PC keybindings is that the Janko-style mapping(which I believe is the default mapping of Chromatone) is the most familiar to piano players, and the least disruptive in terms of playstyle. Harmonic Table is at the other extreme - it minimizes note distances to the point where ergonomics for traditional playing are hampered - chromatics are downright uncomfortable, but you can easily reel off huge jumps around the scale that would otherwise require virtuosic technique. Wicki-Hayden sits somewhere in between those two.

That's relying on distribution package management to save you. Here is what happens when you add libraries in any other context:

The library has a dependency on another library, and when you go look at the dependency, it tells you that it needs to use a specific build system. So you have to build the library and its dependency, and then you might be able to link it.

But then, turns out, the dependency also has dependencies. And you have to build them too. Each dependency comes with its own unique fussiness about the build environment, leading to extensive time spent on configuration.

Hours to days later, you have wrangled a way of making it work. But you have another library to add, and then the same thing happens.

In comparison, dependencies in most any language with a notion of modules are a matter of "installation and import" - once the compiler is aware of where the module is, it can do the rest. When the dependencies require C code, as they often do, you may still have to build or borrow binaries, but the promise of Rust, D, Zig et al. is that this is only going to become less troublesome.

I've been working on a fantasy console, which touches on this "design down" space. It's the kind of endeavor that lets me iteratively redesign to go deeper and deeper into the stack, by starting off with "scripting plus some kind of I/O", gradually extending the concept, and then, more recently, to shift towards using WASM, memory maps, a BIOS layer, and an emulator UI layer, giving me more spec clarity.

The I/O boundaries and resource limits are the really important bits: A web browser is ultimately just a bundle of I/O functions buried inside specialized feature APIs, with only some very specific "patch this" limits for maximum resource consumption. This has allowed the size of web apps to creep upwards indefinitely while not being able to actually do every task, because the feature APIs sandbox in a haphazard "intended for the average consumer" way. When you add in comprehensive limits, the design and the software built on it are able to last: it's the lack of limits that has always created software crises.

One could imagine, instead of the browser as a lowest-common-denominator sandbox, a fantasy system specialized "for text editing", which has a different spec from one specialized "for 3D graphics": This would narrow the scope of sandboxing, make it easier to task-optimize, and yet also create the need for a Lisp or Smalltalk type of system that needs flexibility "for prototyping". It's not an unreasonable path, considering how broader trends in computing are leading towards hardware specialization too.

In another reply thread I mentioned that I'm using a $50 smartphone kit consisting of a smartphone stand(Nulaxy brand, but there are dozens of similar designs) and iClever folding Bluetooth keyboard for writing. I think this is roughly along the lines of what you might want. The keyboard fits snugly in a vest pocket(it comes in two versions - I'm using the larger version with full-size keys and backlight) and gives a decent - not amazing, but good enough that I don't care - typing experience. There are many folding Bluetooth keyboards on Amazon, but this one stood out from the pack.

Combined with the stand to raise my phone I have something a bit more ergonomic than most integrated-device experiences, definitely better than what I would get from a Gemini when a flat surface is available, and I can literally throw on my vest and go for a jog and then take out the kit at a coffeeshop and lose myself in writing without difficulty. You might also need more I/O or a full PC architecture, but this setup was like a "my search is over" moment for me.

My intuition agrees. The threshold of features that OP is looking for amounts to "multiple devices all crammed into one". That is going to lead to a compromised workflow - there's more to configure on your end and you'll lose track of it in a digital sense instead of a physical one. Like with the actual Swiss Army Knife, most of the end result is likely to be unsatisfying as a professional tool.

For ordinary tasks, a consumer device that can SSH in, and ideally do some USB, probably is the right thing. Last week I put together a $50 vest-pocket writing kit with a smartphone stand and a folding Bluetooth keyboard(iClever brand, if you care). And in just a week of use, I've already had multiple strangers remark "I want that" - I can easily imagine using it for coding and sysadmin too. The real limits to client computing these days mostly revolve around operating system and I/O, and you do want to have lots of ports...but mostly on your desktops and servers.

I've been in SF most of my life. The city has been heavily impacted by tech ever since the dot com era, but it's built on some robust cultural foundations: Waves of arts and landscaping projects dating back to Adolph Sutro, the nearby academic influence of Berkeley and Stanford in addition to smaller local institutions(for example, the Exploratorium - a great place for kids, and still fun for adults), a variety of social movements that have swept through the city from the Gold Rush era onwards, multiple ethnic immigrant cultures, and access to nature.

These are things you appreciate and can grow from by living here in the long term, but are easy to miss if all you do is walk around and see low-rise buildings and homeless people. There are far more exciting cities in terms of bustle and grandeur, and more livable, well-maintained, inexpensive cities for everyday activity.

When I set up isomorphic keybindings in music apps I usually aim to cover the entire alphanumeric section of the keyboard. It allows me to play passages both vertically and horizontally. This is good, though, it's a good use of isomorphic behavior.