ManBeardPc

Steam created a platform that works for developers, gamers and the platform itself. It is managed well. They pushed Linux gaming. They are not perfect and monopolies are dangerous but currently they are beneficial for the gaming community as a whole. They have not won capitalism they just have a consistent product that they didn’t enshitify to squeeze out ever short term earnings they can. I only fear that at some point someone greedy takes over and ruins it. Epic failed to create a proper alternative even with a good example and many many years of time to iterate on it.

It makes things viable that previously would just sit in a backlog for months or years because something else is always more important. On the other hand it can create messes that cause a growing backlogs. Can confirm that smaller teams are much more viable now. We are 5 people only.

It's not all boilerplate of course. But iteration cycle is shorter and the latency matters. We are trying find a formulation, so a lot of experimenting, fine-tuning, checking errors (first via simulations, then real-world with measurements). Then we see what needs to be changed, repeat until error is in desired bounds. But the real-world is messy so we see a problem (lets say adding some certain color does not change the final properties of paint the way predicted) and we go back to the customer, some expert remembers temperature/moisture of the air was different on this day and that affects printing results. Now we need to measure this too and add it to the simulation and add it to the data pipeline. But we may have to wait until the real world has implemented that too (create a process, buy hardware, whatever) and then a while later we finally get real data and can start doing our part. Reducing our latency makes things faster, as you may do something else in between and need to load everything in you head again. The LLM gives results in sometimes minutes: frontend, backend and database. We now have the feature branch where you can upload the data like the customer would do, start the calculation, see the predicted formula. From idea to working prototype. We can focus on making assumptions and checking them quickly. Previously they can make the changes in their Python scripts but getting it in a presentable form took much more work. Now we can go to the customer and present a pretty custom made UI like an end-user would see same day they give us new data or report issues.

The stack certainly could need improvement, but much of the overhead comes from the process being pretty serial because each step depends on the previous. If someone we needs to talk to goes on vacation, sick or has a full calendar this delays it much further. Iteration speed is not linear in such cases. We do a lot of custom solutions and have to implement custom parsers or interface with undocumented ancient software or simply no existing software. Everything is custom, because previously they have no processes, no IT infrastructure or simply only data intended for humans (roughly structured, informally written, ever changing naming schema, typos).

Oh yes. Verification needs to be done. Some statistics and validation is absolutely required. Also most customers don’t want their private data uploaded anywhere, so ai gets only test data and writes the script to transform it. As long as it is just XML, CSV or similar it’s pretty reliable. Handwritten notes and bad scans however…

Yes, but they tell things and maybe forget to mention certain things or contradict other data they have given you. Now we may not notice it initially until we make an experiment and get the results. Something is wrong and we have to find out what. Talk to the customer again. Fix experiment. Repeat. Faster experiments means the latency from new data to results is less and we finish the project faster. Errors become less expensive and cause less delays. People make errors and data quality is often horrible so the shorter iterations are nice.

Can’t share more than that publicly. Just that the time saved on this one thing alone is saving us way more money than the subscription per employee that is needed (~100$). I don’t doubt there are companies where this is not the case. Would like to share more details, but the rough math of doing something in a day vs several days + engineering salary have to do here.

No, but if we go from data to experiment faster we see earlier if something is wrong. Once we get data we quickly can fix the data pipeline and get results. If there are issues we can quickly show what/why and discuss it with them in detail and make changes based on their response faster.

A lot in this world is not optimized by software yet. For our customers they have employees with decades of experience guessing things, maybe some software that kind of helps but still not good enough (slow, not finding really good formulas). They often have difficult problems and many failed projects. We try to find such customers and offer our service. If we are cheaper (+ show portfolio of successful projects) more are willing to give it another try with us.

Tons of unstructured data that needs to be cleaned up in so many different ways that are hard to predict. Knowledge distributed in the heads of greybeards, handwritten papers und excel, sharepoint and dozens other locations like ancient proprietary software. Which you have to repeatedly ask for and discover more piece by piece. Then clean up, discover issues, make the customer gather more data/correct it, etc.

Not all experiments work out. If we find the right approach faster we can finish the project faster. Some projects are mostly fixed price or offer bonuses for reaching milestones in a certain time. Meaning we more often get a bonus and can take more projects. Also we can take projects with tighter deadlines that we would need to decline otherwise.

Does for us (data science, specialty chemistry, finding/optimizing formulas). We can get from idea to prototype in a day compared to 1-2 weeks. All that boilerplate to process data took a long time to code by hand, especially for the data science/math guys who are not programmers. Now we can actually try all ideas instead of guessing the most promising and only try that.

The Record struct contains rtype and data where RecordData is a tagged union. Aren’t those two always in sync? Not a DNS expert, just wondering if this is redundant or there is a reason both are there. Doesn’t matter anymore if they store it already serialized but I would be interested why it was this way.

Don‘t know any other runtimes that have that by default. Probably kind of possible in Erlang or so by transferring the state, but stopping and moving a green thread in the middle of execution I’ve not seen elsewhere.

Last I checked (and remember right) they used Stackless Python. Very interesting, it can serialize tasklets and send them to another machine to continue executing. Seems no longer maintained though.

It was an improvement in some regards, but a pita most of the time. Before I had to work on an Angular project React was my least favorite frontend library. Solid.js gave me back my sanity (also Svelte 5). Fast, small, includes what I need and feels like just writing JS/TS. Sadly businesses love to torture their developers, themselves and users too much, so React/Angular it is.

News in general. Also works well in sales, see how often financial "advisors" try to convince people the market is crashing soon and everything except their product is unsafe and how they try to mitigate downsides (active funds, low/zero interest savings accounts).

The endgame is to normalize punishing groups/individuals for any reason on a whim of the ones in charge. Start with minorities and people who can’t defend themselves, then later you can do easier to anyone who gets inconvenient. Despotism 101.

My next company‘s boss was pretty much Windows only (server and desktops/laptops, some Linux servers). Linux on the server was already replacing more and more machines. Now I am even allowed to use MacBooks or Linux laptops. Current company is already using the Google suite, MS Office was an exception if required for some reason. I saw the same shift with Oracle. Previously nearly everyone wanted Oracle as a DB, then the price increases got too much and everyone who could switched to alternatives like MySQL or Postgres.

It will be a big one for people living near the coast. Basically all port infrastructure will need to be moved. Of course there a things like extreme heat waves, cold snaps, lack of rain or floods that will make a lot of land unlivable too. Lack of food will be another thing. But land being under water is not a lesser thing at all, as it makes the land unavailable.

Yes, that is exactly what is happening. 2000W solar panels feed the battery, up to 800W are allowed to be fed back into the grid/house network. Keep in mind you could also plug a 3000W device directly into the battery, meaning you could power a lot more than that if it is not connected to the grid. If you have devices that need little power for a long duration or high power for a short duration they can be fed with 100% solar that way. Depending on your use case that can save further money.

The awesome part is you can circumvent the 800W. First you can legally install 2000W solar panels, making 800W output much more likely. The 800W is only how much you can feed back into the grid. Second you can install one or more batteries and feed devices from them, further increasing the usable energy.

Huge barrier of entry. It requires a lot of integration and investment. Getting another supplier to move usually involves handing over big bills. Even then it is not guaranteed that the change is (fast) enough. I see it all the time, nobody gets their ass up unless it’s on fire. Still some companies will claim „at least it’s warm now“. „This is fine“-meme is real. Resist change at all costs.

I’ve seen companies losing their by far biggest customer because they refuse to hire real engineers instead of juniors to fix their software. The customer tried YEARS of complaining before.

Another customer: different suppliers use different barcode patterns for deliveries, some including nasty stuff like NULL as separators (but only sometimes, can be space, tab, whatever) or non-unique IDs. They rather spent the effort to fix everything else with workarounds than change the contract and demand proper barcodes/delivery data.

Regarding async I kind of agree with you right now, but the new design is there and currently getting implemented. If you don’t believe it will work out or need to use async right now sure, use something else. It is not a stable language yet and very much WIP. I don’t think it’s dishonest to write about something that has a design and is worked on right now with a realistic chance of working out.

The point is the code is on another type. Any variable could by of a type that implements some Drop logic. It is mostly called implicitly where it is used, wether you as a programmer are aware of it or not. You would need to check.

In Zig you need to call everything explicitly, meaning in the function you need to call what you want to be executed, no other code will run. The decision if you want some cleanup logic is made at the point of usage, not by the type itself.

That is the point of it, you look at a function and directly see what happens right there, not in other files/packages.

Drop yes. Thanks for the correction.

It is clear when it is called, but you have to check in code you are not currently seeing as any type could implement it. May seem like a minor thing, but is not explicit at the point of usage. In Zig only code you call explicitly runs, meaning if there is no defer nothing happens at the end of the scope.

Not only being text based but also having another separate language is problematic. Rust also has powerful declarative macros but it is it’s own language. Procedural macros and crabtime are imho a bit better for more complex cases as you write Rust.

You can ofc use the *alloc from libc if you want. Otherwise there are different ones in the standard library, ArenaAllocator wraps another allocator, FixedBufferAllocator uses a given byte slice. I recommend to take a look at https://ziglang.org/documentation/master/std/#std.heap to get an overview.

It has proper arrays and slices, even being able to define a sentinel value in the type system, so you know when it is a C string or a slice with a specific size with arbitrary values. Strings can become a problem if you need another encoding than the chosen one. Then you start to use byte slices anyway. You need to allocate a new one if you want to change just a part of it. Safer yes, but can produce unwanted overhead and you have to duplicate many APIs for strings and byte arrays as it is the case in Go.

Comptime is very nice but certainly more limited then Lisp. You can't generate arbitrary code with it. But good enough to implement something like JSON serialization or Struct-of-Arrays in normal code that is readable.

Custom allocators are very nice. We are very much in manual memory management + optimization territory here. Having things like arena allocators makes a lot of difference in specific use-cases when you want/need every bit of performance. Also nice being able to switch the allocator for tests that is able to report leaks for example.

Yes, hidden control flow I mean something like exceptions, RAII or Rust's Dispose. So more a comparison to other languages than C.

The explanation I would refer to the talks "Don't forget to flush" or "Zig Roadmap 2026" from Andrew Kelley. Also the blog post "Zig's New Async I/O". I think it has something to do with being able to infer the required size of the stack, but already forgot the details.

https://kristoff.it/blog/zig-new-async-io/ https://youtu.be/f30PceqQWko?si=g2nLTE4ubWD14Zvn https://youtu.be/x3hOiOcbgeA?si=SUntYOYNOaxCRagc&t=3653

As to compared to Rust. The fast compile times are nice. Having a small language that you actually can understand helps to be productive. Not being restricted by the borrow checker makes it easier to implement some low-level things. Just being able to import most C code without wrapper makes the smaller ecosystem a much smaller problem. Rust is nice and certainly a good pick for many cases, but personally I often feel overwhelmed by the complexity and tons of tons of types for everything.

Like a modern C with lessons learned. Instead of macros it uses Zig itself to execute code at runtime (comptime). Custom allocators are the norm. No hidden control flow, everything is very explicit and easy to follow.

But it’s not only the language itself, it is also the tooling around it. Single unit of compilation has some nice properties, allowing to support colorless async. Fast compile times. Being able to use existing C code easily and having optimization across language boundaries. Cross compilation out of the box. Generally caring for performance in all aspects.

So for me it is a better C, low-level but still approachable and not having so much cruft.