For me it depends a lot on the context. JSON is often very human readable (as long as it's not too deeply nested), fairly well defined (compared to CSVs), and most languages and software have easy out of the box support for parsing and manipulating it.
If I were building a system that had to deal with large amounts of tabular data that isn't directly consumed by humans, JSON wouldn't be my first choice nor my last.
> Garbage collection tasks are postposed to when we're asleep, but they can only be put off for so long and there's a capacity for "stuff to consolidate later" that fills up
Do we have a strong reason to believe that? I know brain and sleep mechanisms are tricky topics with lots of unknowns, but I thought I had read research that showed sleeping brains likely perform a chemical analogue to "garbage collection".
I can't shake the feelings that a trillion or a quadrillion parameters won't solve the fundamental shortcomings of ML models not being models of artificial intelligence. I guess there's no way of knowing until we reach AGI, but I've never heard a compelling argument for why pure ML would get us there. GPT3 seems more like an argument against that hypothesis (in my view) than for it. Even the best, most expensive models today are incredibly brittle for enterprise usecases that shouldn't necessarily require AGI.
I've always imagined AGI (perhaps naively) as being achieved by clever usage of ML, plus some utilization of classical/symbolic AI from pre-AI winter days, plus probably some unknown elements.
Likely a joy for Rust and a desire to try something ambitious that hasn't really been done.
Rust doesn't have the mature libraries that C# offers, but it isn't barren anymore either. It does offer nice assurances like entirely avoiding race conditions by default (when using safe Rust). Rust often leads to performant code, but it's hard to say if that's really a feature of the language or just a bias due to the kinds of people using it and the projects they work on.
If you're just looking to get into game development without any other goals in mind, then C# is a safer choice
I hope this will encourage big studios to stop releasing broken games, but I doubt it will. The incentives are just so broken due to ease of patching, a need/desire for cash after a drawn out dev process, and a general disrespect for their customers.
I think releasing a "broken" game in the form of "early access" from smaller studios can be good in terms of iterative and community development, but also that can be abused too. These bigger studios really don't have as much of an excuse in my opinion.
The only solution I see is to stop pre-ordering games and don't reward studios that do this, but easier said than done.
Yeah people are "lazy" in that they don't want to spend precious few free hours of their weeks grinding out a gimmicky skill-set that is at best tangential to the actual work they would be doing.
I understand there is no simple solution to how to hire software engineers, but you should be able to recognize why a lot of us don't like the current status quo of interviewing (even if you thrive in it).
I still don't see how this has anything to do with decentralization, and frankly the way you're justifying it sounds like you wanted to use a clickbaity word that doesn't really apply here.
How does this help data ownership? How does this decentralize the 'power structure'? The ownership and power is still in the hands of the server. The benefits you highlight here are addressed by SSL. Is this trying to address the downsides of SSL? I can't see how it is/would.
It seems like 'frictionless monetization' is the only thing this really addresses, and even that I'm skeptical of.
I don't mean to be such a detractor, but you really need to reconsider what the purpose of this technology is and sell that purpose better. Because your current explanation makes no sense.
I led a hackathon team in an in-person 24 hour hackathon, so it's not exactly the same but here's my advice:
- Getting people excited means giving a good elevator pitch and following up with any specifics you've mapped out. Tell them what you're trying to solve, why you're solving it, and how. Engaging with feedback/criticism of the plan will help get interested people on board. Make sure you try to match people's interests to the work to be done. I.e. assigning a backend-oriented person to do frontend work is a great way to kill motivation (unless of course they've requested it).
- For remote: make sure you have clear lines of communication and a clear delineation of work. Be available at a moment's notice to answer any questions.
-- a Slack channel (or something similar) for your team for ad hoc, asynchronous communication is a good idea
-- daily standups over video/voice would be a good idea. Make sure to take longer conversations offline as to keep everyone productive.
- As far as structuring the week that's harder to answer. Map out the work to be done, break it up by person, and then giving a loose timeline with some wiggle room. Something like a Gantt chart could help here, but there are a number of ways you could organize this.
I wouldn't care as much if they weren't simultaneously sacking their work force and ending work on popular products. I'm sure Google is trying to paint them in a bad light, but honestly it's not hard with the current leadership and doesn't take any dishonesty.
Interesting! I guess that makes sense but I definitely would have underestimated that cost.
In this case the cost seemed to apply in part to 3,000 cameras. But solely based on the article, it's hard for me to tell what portion of that $30 million went to upgrades/maintenance and what portion went to the cameras. However it does clearly say it would be another $7 million to maintain the cameras over the next four years.
Depends what your metrics are, but very likely no. Even if you could prove it was a "good trade off", good luck convincing anyone. In America we're seeing how stubborn people are to take any actual steps against a deadly virus, they would absolutely scoff at any intrusive measure meant to prevent the flu.