Frameworks aren't just human-serving abstractions - they're structural abstractions that allow for performant code, or even being able to achieve certain behaviours.
Sure, you could write a frontend without something like react, and create a backend without something like django, but the code generated by an LLM will become similarly convoluted and hard to maintain as if a human had written it.
LLM's are still _quite_ bad at writing maintainable code - even for themselves.
Mirroring what many others have said, Azure is often broken and generally frustrating to use. Performance is also often _quite bad_ and there will be frustrating network limitations based on seemingly unrelated configurations. For example, we discovered that we could nearly double the download speeds to our webservers (downloading from Azure storage even) by upgrading to a beefier SKU. This may sound reasonable on the surface, but we were seeing speeds of only ~10Mb/s, often less. Even now, we see extremely slow download speeds and it is dependent on time of day - slowest during peak business hours and faster in the dead of night. I understand network congestion, but this just seems completely absurd when we're talking about servers that both exist within the same Azure region - likely in the same DC - having worse download speeds than I get from my $5 DigitalOcean droplet to my house.
Many will disagree with me, but the Vancouver Olympics prompted construction of some things that I would consider vital to the Sea to Sky region - the highway upgrade being the biggest.
Many will disagree with me, but the Vancouver Olympics prompted construction of some things that I would consider vital to the Sea to Sky region - the highway upgrade being the biggest.
Tide is fantastic and has IMO the best ergonomics (and could be improved to be even better), except it's essentially abandonware at this point. I'd love to see it continue and thrive, but there's many PR's that have been ready to land for a long time gathering dust, and plenty of open issues that are at a standstill because there's simply no momentum or direction.
Not blaming anyone - the maintainers don't owe us anything - it just wouldn't be my crate of choice if I was starting today. If any of the maintainers read this, shoot me a message because I'd love to help out and get the ball rolling again on tide.
Agreed - honeycomb has been a boon, however some improvements to metric displays and the ability to set the default "board" used in the home page would be very welcome. Also would be pretty happy if there was a way to drop events on the honeycomb side for a way to dynamically filter - e.g. "don't even bother storing this trace if it has a http.status_code < 400". This is surprisingly painful to implement on the application side (at least in rust).
Hopefully someone that works there is reading this.
Still early days, but we've been using CBOR instead of JSON lately at work for interfaces that have "settled" and it's been great. Means that you can shake out the early integration issues using human readable JSON, then just switch the ser/de once it's all playing nice.
Binary data support is pretty nice too for avoiding multipart request bodies.
Check out Qutebrowser. It's almost entirely usable from the keyboard only using vimlike bindings. Lags behind chromium/qt a bit for the actual engine, but these days it's totally usable and has become my daily driver.
Forgetting that BC exists entirely. If you search "Kei" on Craigslist Vancouver, there's currently 37 postings, and they're constantly being imported here. I see them in Washington as well, although those may be Canadians just visiting.
In the PNW these are absolutely everywhere and for good reason - they're exactly what most people need when they need a truck bed for hauling capacity. Plus, many are 4/AWD and have relatively high clearance so they're great adventure wagons for forest roads and getting out there.
If a manufacturer made a truck similar (or slightly larger - not much room for people 6' and over in them) available for the market here, I'm sure they'd sell well. Seems like the biggest impediment is the safety laws here though and American insistence on having the biggest vehicle on the road.
Including secrets in the compiled binary seems questionable still - using env variables or a config is the "standard" way for secrets, and although it adds another step before you can run, it avoids the case of sharing your binary with someone and forgetting that you had compiled in some secret that goes unnoticed. Unpacking a binary to find strings is pretty trivial.
Having the static frontend assets baked in along with a default config is a huge boon though.
Freestanding rigs do exist, but as you're likely aware, they transfer all their loading and stresses through their mast step - most often being stepped through the deck so you essentially have the full hull height worth of support. Not sure which AC class you're referring to either - all the wing based boats absolutely have standing rigging, they just don't have spreaders since they're rotating masts.
Even if this proposed mast is stepped through the entire container, the forces on it will be plenty to cause issues since the containers are only held down by neighbouring containers and the 4 anchoring twistlocks. This proposed design will 100% require standing rigging to support it - the claim that the rig will only experience 10s of kn of loading is almost certainly incorrect as well - 30ft racing sailboats will experience loads exceeding that at the chainplates regularly. The moments about a mast are huge, even on relatively small rigs.
The difference here is that a cat or dog hasn't been trained to write a python program, and it probably isn't possible - the weights and activation functions of a cat brain simply won't allow it.
This is sorta how many "embedded" systems with a display work these days. Start a chromium window in kiosk mode at boot and use a webapp for the UI. You'd be surprised how many touchscreens out in the world do exactly this.
I've gone through the process of auditioning a bunch of rust webservers as well and came away with the opinion that of them all, Axum and Tide have the best interfaces and features. We went with tide, and I still believe that it is the _easiest_ to use in most cases - just with a few quirks that need to be changed and features added (or in some cases just be made public). Sadly however it is not very actively maintained and I fear for its future as that compounds with less and less people choosing it over time.
Axum by comparison has a very active community, but I found it's request handling and middleware concepts much less ergonomic. If you're debating between rust webservers it's worth taking a look and giving tide a chance. The async-std choice hasn't been an issue for us at all either.
I think this is a symptom of using weakly typed languages as well. If your argument types are declared to be options/eithers, then you need to handle the empty case, but usually it's easier and better to just move that optional handling further up the callstack or type system.
A lot of `if (input == null)` checks are because you're just not sure whether the argument being passed in will have a value, and it's too much work for your small feature PR to refactor the whole codebase to resolve it.
Use typescript/python-with-mypy/haskell/rust/whatever and this problem mostly disappears.
Sidebar, but I care about the headphone jack issue and am still annoyed by it.
Bluetooth headphones just aren't very good, and we've all gotten in the habit of buying a new pair every few years because they either break, get lost, are unsupported, or have bad batteries.
I previously had the same pair of IEMs for almost a decade that had better sound quality, replaceable cables and eartips, and didn't ever run out of battery. Never did I complain about the cables being annoying or in the way, and never did I complain about the presence of the headphone jack, or the Bluetooth chip onboard.
Removing headphone jacks was a horrible misstep in my opinion and we're stuck with the path dependency it's created now. It's probably not long before we have laptops that omit 3.5mm audio jacks as well.
Sure, you could write a frontend without something like react, and create a backend without something like django, but the code generated by an LLM will become similarly convoluted and hard to maintain as if a human had written it.
LLM's are still _quite_ bad at writing maintainable code - even for themselves.