HN user

mdtusz

571 karma

[ my public key: https://keybase.io/mdtusz; my proof: https://keybase.io/mdtusz/sigs/FAD2AvtLKbt5IeNmKeXTCV-CJhFYm-csNwRK7Ewlz7w ]

Posts2
Comments198
View on HN

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.

Azure storage is absolute hot garbage.

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.

LazyVim 3 years ago

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.

I'm sure many will disagree, but just implement it yourself if you're an SP.

If you're using a common web framework, there's almost certainly packages/plugins that will manage SSO and 2fa, and despite the constant fud, dealing with user accounts really isn't all that hard. More importantly, understanding the mechanics of your user account system will pay dividends as your product grows and new authN/Z requirements arise.

I use my desktop at home exclusively for gaming. I had Windows on it, but it would continually crash when trying to use my bluetooth xbox controller with it.

I've switched to linux for gaming and have no issues, even running games like GTAV (excluding the occasional nvidia BS...).

I've seen this happen as well, but I think it's more of a problem of bundling too small a changeset in a release. A partial implementation of a feature shouldn't warrant a release (without feature flags to disable it), but bundling a year's worth of work in a single release is, in my opinion, a recipe for disaster (and this is sadly something that happens all too often in enterprise and non-software engineering businesses).

I'm curious why you think it's too big to master. There's certainly a lot to the language, but it's design means that these various facets are largely contained to their area of effect. I'd be confident in the assertion that most rust developers don't need to understand much more than the basics of the type system, traits, lifetimes, and the surface levels of async.

The biggest benefit to the language is precisely that all the Lego pieces fit together and you simply don't need to worry about (in Lego parlance) "illegal moves". Whenever I write C or C++, I'm constantly worrying about whether or not I'm doing something incorrectly and potentially writing dangerous code. In rust, this mostly disappears and you can focus on the actual problem domain you're working in rather than computer science problems.

On Linux, the official teams application crashes constantly and most often doesn't work at all for video or audio. Fine, I'll use the browser version then. Except the browser version won't load 50% of the time, brings my laptop to an absolute crawl as soon as you start a video call using up 100% cpu, and frequently will crash any other teams or outlook tabs, or often times the browser entirely.

It's borderline unusable on Linux, and I've reverted to using it on my android tablet where it is only marginally better and still has issues constantly with audio, as well as crashing when starting up, or "updating" and somehow running two simultaneous instances of the app with only one visible. Also the notifications for when someone calls has never once worked on the tablet, while simultaneously I'll get nonstop repeating notifications for meeting chat messages from a week ago.

I'm sure for many people it works just fine, but for many others that aren't exactly on the Microsoft happy path, it's a nightmare.

The problem is that you said you're not athletic or not a conditioned athlete, then described exactly what it takes to become a conditioned athletic person - dedication to training and putting in the mileage.

Anyone that can run a half marathon every weekend and 30km+ during the week is almost by definition athletic. Yes, nearly anyone can achieve this with the dedication it takes, but that doesn't change the fact you're being overly humble about your own athleticism.

It's like someone saying "I'm not an engineer, and am not particularly good at math or physics, but I studied 3 days a week and got an engineering degree and now I work at an engineering firm and can solve most math and physics problems."

Infant speak for all IdP's but Azure allows for configuring a sign out url to solve this issue - when the user signs out of their Azure AD account, the sign-out url is called so that the application can revoke the users session.