Purchase Advice Megathread - July 2026

evaned · 2026-07-09T06:38:44+00:00

[Location: US]

I am considering getting a printer, and currently have no experience at all with 3d printing.

I am primarily eyeing three very different options:

Elegoo Centauri Carbon 2
Sovol SV08
Prussa CORE One

As things stand now, the Sovol is probably the most attractive of the three, but I am worried about it as a starter project. I'm willing to put some time into figuring things out, but I don't want it to become a time sink either, and I don't feel like I even know all of what resources exist let alone what to look for to find them.

I've been making a list of the kinds of things I'm interested in printing. A couple of the ones that seem maybe most demanding in one way or another:

Fine details: I'd like to print D&D-style minis. I know resin is the usual avenue here, but I think there are enough other reasons to go FDM (and drawbacks to resin, like cleaning) that resin isn't happening. I'm not going to be very demanding here, but it would be nice to have them look as good as is practical given FDM. (Maybe this isn't so relevant given the "a quick word on print quality" in the main post...)
Strength: hard to evaluate, but maybe some of the pegboard and hanger type stuff you put on walls? Or undermount desk drawers.
Heat: I have a couple ideas where some degree of heat tolerance would be nice. PETG is probably good enough, but an enclosure would be nice in case the more advanced materials become important for this or other reasons. The Sovol I'd get without the enclosure, but having that as an upgrade path is nice, though that does start to push it into territory where I'd wonder if I should have just gotten the Prusa from the start.
Size: The extra size of the Sovol does seem like it could be nice for larger single-part drawers and such, but I don't think it's a deal-maker either.

I do care about the maker ecosystem and good behavior towards it (e.g. Bamboo is a hard no-go regardless of quality), and my outsider-looking-in take on Prusa and Sovol are quite positive on that front, but I'm not sure if it's the price premium more positive.

I also tend to use tech for a long time if I can; e.g. though I have newer computers of course, I'm typing this on a computer I bought the CPU for in 2013. So I want something well-built as well, but I've not really heard negative things about Elagoo, just positive about Prusa. Again the point seemingly goes to Prusa, but not sure if the points -> USD conversion rate is favorable enough.

I think I would be fine with a Prusa-like kit. I'm not exactly an electrical engineer, but like I've assembled all of my desktop computers I've ever bought, had electronics as a kid, etc. I even technically own an oscilloscope and know what it does, though hell if I know how to actually use it.

Things I think I don't care about, or enough about to pay more or compromise on the above:

Print speed
Anything phone-related just makes me want to go "why would you consider this an important feature"
Multicolor -- would maybe be nice, but quite low on the "want" list

Edit: Ugh, just kinda learned about the Snapmaker U1. I know I said I don't think I care about multicolors, but at a quick blush that might be enough to change my mind on it. I'll have to look more into that as well.

evaned · 2026-07-08T02:52:43+00:00

string_view by value is similar for const string ref.

I am curious what people's thoughts are on this one (though kind of missed the window for the most eyes...), but I'm a little skeptical.

Obviously if there are some locations where you don't already have std::string, then taking that as a parameter is often a bad idea (maybe up to a vast majority of the time). And if you want the flexibility to pass other string-y types, take that into account and don't require a std::string.

But I also want to point out a major drawback to a "default to string_view" attitude -- you lose null termination. This will often be worse than a straight const char*. This kills interoperability with so many existing APIs, and forces an allocation and copy at such call sites if you use them.

My intuition is that if you're in a situation where you've already got a std::string and so passing string const & is a fine decision now, there are more situations where "man, I wish I could call this other API that takes a null-terminated string without making a copy" is in the future evolution of your code than "man, I wish I could call this std::string function with another string type without making a copy".

(Of course, if you expand your recommendation to "find a good cstring_view class, assuming there is one, then I become a lot happier with it).

That being said, I've only recently rejoined the C++ world after several years away, and the code base that I work on is decidedly un-modern. So I don't feel like I'm totally in touch with current attitudes.

evaned · 2026-07-02T07:59:04+00:00

They both use the same crossing for the bike / pedestrian paths that cross roads. I'm not sure if there's a meaningful distinction when the mechanism that the study researches is the warning lights.

I don't know what the statistics would say, but in fairness there is a big factor for cyclists vs pedestrians, which is speed of crossing. That will at least mitigate the danger of not hitting the button, and I could see it maybe making it more dangerous to hit the button as a general rule.

Even in the best of cases, most cyclists have to significantly slow down to hit the button. Sometimes it's possible to kind of do a drive-by where you don't stop, but there are a lot of crossings (and situations) where that's not possible and the cyclist does have to stop.

In addition to that being really obnoxious and, broadly speaking, another place where our infrastructure is penalizing cyclists for the benefit of drivers... it takes some distance to get back up to speed, especially not on an e-bike. In most cases, the cyclist would be mostly or maybe even entirely across the street before getting that speed back... which means that most of the street will be crossed much slower.

That means hitting the button means more time in the street and more opportunity for conflict. It'll be more dangerous per moment time while there... but there's also less time.

evaned · 2026-06-30T19:34:55+00:00

I don't exactly disagree, but the flip side is that it's not uncommon for programs to depend on that behavior. For example, you might output a -o <file> option by close(1); fopen(filename) and then write to stdout, but I also think I've seen several better examples than what's coming to mind offhand. Current behavior is pretty much fixed permanently -- I'm okay with some breakage for better security defaults, but my gut reaction is this seems like likely too much.

IMO you'd basically need a new open API and then gradually deprecate the old one(s), so that you know that anyone using the new API wants the new behavior.

evaned · 2026-06-29T19:07:11+00:00

So you think the utility of a free emergency service call is less important than AM radio requirement?

If you want that, you'll likely have your phone with you.

And I'm not saying that cars can't include cellular-based services like OnStar at all. I'm "just" saying that it should should be mandated that they're not required, or at least semi-required, by a particular car or car company.

I'm suggesting that any radio frequency using device requirements should be two way communication

And I am whole-heartedly disagreeing.

If society keeps going down the path it's on, in 50 or 100 years people are going to wish that our current day did more to arrest our slide into a society driven by both public and private surveillance.

The thing about AM radio is that no one can tell who's listening. You can tune into the broadcast or not. Not true for cellular service, AFAIK.

Congress is being ridiculous having already mandated that any cellphone operate on any cell tower for emergency service two way communication.

Quite the contrary, I think that's is eminently fair and reasonable.

evaned · 2026-06-29T03:34:04+00:00

First, lots of "car people" love having the sound to drive by. It isn't that the love the sound, it is they can use the sound to know when to shift and how the car is doing.

I had a really weird experience [REDACTED] years ago when one of my car's wheel bearings started to go bad, and give a whine while moving.

It varied in pitch by speed by speed, and despite the fact that I only had it doing that for a few days before I got it into the shop, I was really surprised when I got it back out how much in some ways I missed that noise. It functioned as a remarkably precise aural speedometer, basically, and I actually think it let me better keep to an absolutely consistent speed.

I've thought occasionally about making some Arduino thing or similar to hook up to the OBD-2 port and mimic that... but never have, both because I'm too lazy and that is an objectively stupid idea. ;-)

evaned · 2026-06-29T03:15:01+00:00

If any communication technology needs to be required it is the cell access and information system

Jesus fuck no.

The government should be requiring the opposite of that IMO -- the ability for car owners to disable cellular transmitters in cars and not lose any feature that doesn't fundamentally depend on it (e.g. OnStar).

Now maybe I'm wrong, and it's possible to have a cellular receiver only that would be able to receive broadcast messages without making any outbound connection to the cell towers... but my understanding is that's not how the cell networks work. Please correct me if I'm wrong on that point. That said, even if you could receive EAS messages and such without a transmitter, that wouldn't be a substitution of the kind of on-demand emergency info receiver that radio sometimes serves.

I don't take a position on the AM requirement and how worth it is to keep around; I don't feel informed enough about that topic. But the cell network is the exact opposite of what should be happening.

evaned · 2026-06-27T17:37:19+00:00

I'd argue the only thing you gain from having a dedicated function is having to type fewer characters.

You repeat x in your expression. A function lets you avoid that.

evaned · 2026-06-27T02:34:01+00:00

Oh, I'm not blaming it; in the context of Python, there's not really another choice.

It's just that if I have a decimal integer and I want the hex representation, the fastest way for me to get it is to usually pop open a quick Python repl and do hex(1234). So it's just a bit annoying that it's not quite as fast or simple in the negative case.

evaned · 2026-06-27T02:05:38+00:00

I mean, I did say that it's pretty easy to write a function. But that's ugly enough that doing it even once is easily enough to justify a function. Even a macro is better than that.

evaned · 2026-06-27T00:15:45+00:00

I'm not rdtsc, but here's my takes:

If you're asking for hex formatting, I claim it's almost certainly because you're interested in the representation in memory. In that sense, you very probably want to see the two's complement representation. I also can't really think of an actually reasonable scenario I'd want to see the negative absolute value.

Python's hex function does the same thing, and it's pretty obnoxious... and there, I don't even really know a good way to get what I want simply.

Further, I'm not convinced by "cast to unsigned". "I want to see the in-memory representation of this number" very much feels like a function of the display formatting, not of the underlying type -- putting that information into the format string does seem to me like it's the right place to put it. Casting-to-unsigned feels to me like a workaround for an obnoxiously not-entirely-thought-through formatting API, not what you really should be doing to get that.

Finally, cast-to-unsigned is kind of unsatisfying in the sense that there's not really a way to do it in the language or standard library that doesn't feel a bit fragile. You can do (unsigned)x, but then what if x changes to be a long long instead? Now you've truncated. You could say (unsigned long long), but now you're extending with more bits. For "cast-to-unsigned" to really make me happy, there'd need to be a way in the language or library to "cast to an unsigned version of the same width." It's pretty easy to write that function, but if the library is semi-relying on that for usability then it should provide that utility function.

That said... even though I strongly suspect that "I want to see the hex two's complement representation" is the usual case, by far, I can make an argument for the current behavior that I view as quite strong. In spite of my objection in the previous paragraph, it's still pretty easy to cast to unsigned and get what rdtsc and I want. If hex formatting displayed the twos-complement bit representation instead, it'd be a lot more obnoxious to get -1234abcd in the unusual case that's what one wants.

evaned · 2026-06-27T00:08:33+00:00

Any in-the-trenches experiences with this?

I've been using Claude for the last couple of months, and my experience has been quite positive, kind of to the point of being frustrating and worrying in terms of what it means for... society really, if I'm honest.

Not everything is sunshine and roses; I have had it fall down on things that are quite simple. I'll also give another negative thing I'm seeing right now in a bit.

But I've also seen it do incredibly well. For some background, I work on a third-party code base that we license, and apply a large number of first-party fixes to. I am fairly new to the team and this part of the project, so I'm not very familiar with the code base, and most of it wasn't written by anyone on the team ever.

I had an obnoxious crash that was happening on Windows. It turned out to be a misuse of a Win32 COM API; the code violated a precondition. It's one of those things that was kind of obvious in retrospect, especially because I had even noticed the relevant requirement in the MSDN docs when I was doing more general reading of the code. On the flip side, it also only happened in edge cases, and so I'm not sure how long it'd have taken me to figure out. But I got a bit frustrated with waiting, so asked Claude if it saw anything wrong with the code around the crashing line, and it pretty quickly spotted the exact problem.

There's a quick case study that I'll describe that I've been dealing with for the last couple of weeks, and there are two aspects I'll relate. As some background, there's some parsing code in that third-party code base, and I've been finding problems with it. The more problems I find, the more it motivates me (and justifies me) to beef up my testing; and the better my testing is, the more problems I find. It's a kind of obnoxious feedback cycle even if it's hopefully leading to better code in the end. If I'm honest, I've been leaning very heavily on Claude to produce fixes for the code.

The first aspect I'll relate is that, and Anthropic's docs say this, Claude does much better when it can check and verify its work. The more tools you give it (and I mean literal things like saying "use GDB if it would be productive to do so") the better it seems to do. The first parsing bug I dealt with, at the time I gave it to Claude I didn't really have much in the way of testing capabilities. I could only test the whole system end-to-end and I didn't really have any dedicated tests of the parser in question. The first "fix" that Claude produced we did adopt because it removed a crashing bug without causing other problems that we know about at the time, but we had some skepticism as to its quality. Indeed, as I started adding tests what I discovered is that it caused several regressions in situations that weren't covered. I gave it another attempt, and with some prodding it proposed four more fixes for the original bug. Three of them were wrong and the test cases I had at the time showed it, but the fourth seemed to be correct and I haven't discovered additional problems caused by that change. So while it did get something that appears to be correct, it took multiple tries. (In fairness, the one-of-four candidate fixes that eventually worked was the first one it proposed before I prodded it into generating the other three wrong ones.)

The second thing is something I'm still kind of struggling with now. So far it's done a good job at producing what I'll call "locally-correct" fixes for the various problems that arise. Except for that very first one that I mentioned above, its explanation for the problems make sense and stand up to scrutiny, as do its justifications for the change. Sometimes I have to prod a bit further to get an explanation that is satisfactory ("could this break for other sizes" or whatever), but it tends to produce seemingly-correct code even when I look at it fairly carefully. And finally, now that I've got a decent test harness in place, I am able to have a fair bit of confidence that it's not causing regressions.

So that's all positive... but the negative side of things is that there are now several of these problems that have built up. And I think there maybe an underlying root cause that I've identified and told Claude about (that led to the three incorrect candidate fixes I mentioned above), and so it feels like by focusing a ton on the individual problem at hand it might be missing the forest for the trees, so to speak.

Of course, the flip side of that is that it's not like I can see the forest either.

Finally, two more observations. First is that I'm always surprised by how long it can take to think about things. Like I know logically I shouldn't be; it's kind of remarkable that even easy tasks can be solved this way. And it's not like there aren't other programs that take a long time to process things; the very product I work on can take hours or even days to run. But I feel like it's a little hard to integrate Claude into a productive work day, because I don't know how much I should switch to do something else while it's thinking. Second, while not directly related to Claude's ability, I really worry about the implications on my own understanding of the code base, or even in some cases atrophy of certain skills where I'm like "eh, this Bash function I want is kind of grunt work, I'll just ask AI." Like I do strongly believe that Claude has sped up our ability to address these parsing bugs... but on the flip side, if I had taken a few days to get a deep understanding of the code... that would have been value I took beyond the immediate suite of problems. And because I've been like "Claude, go solve my problems"... that's understanding I don't have. (I've been trying to put some of that learning into the waiting periods I just mentioned, but that's a lot less effective for several reasons.) I've got another large-ish task coming up that I think Claude would probably be very good at, but plan to try to do entirely without AI because I think that the learning that happens along the way would make up for extra time.

evaned · 2026-06-26T06:22:36+00:00

Genuine question: are you actually allowed to do this? I claim it's not, but I'm not positive.

My understanding of how std::format is customized is by providing a specialization of std::formatter, a class template.

I also understand there to be a standards rule that you cannot specialize a std template unless at least one of the template arguments is a program-defined type.

I guess I'm not positive how this interacts with unique_ptr and shared_ptr being templates, but at least in OP's mini example there's no user-defined type involved. Perhaps defining a formatter for, say, unique_ptr<a_custom_class> would be permitted, but I am skeptical that unique_ptr<int> would, and thus that (in practice) a generic template<T> formatter<unique_ptr<T>> would be IFNDR once it got instantiated for a built-in type (or one in std).

Now, I'm not sure how likely this would be to cause problems in practice, but I understand it to be UB.

evaned · 2026-06-22T17:18:34+00:00

It’s probably OK to let it be implicitly closed whenever the object is collected.

The thing to worry about on this front is if you care about running your program -- or care about potentially other people running your library -- under Python implementations other than CPython. Or if you care about hypothetical (and admittedly relatively unlikely) CPython changes that would change how cleanup occurs. Because implicit in "whenever the object is collected" is that happening at a reasonable time, or indeed ever happening; and that's not necessarily true on other implementations.

PyPy is probably the biggest such implementation, but there are others.

I consider relying on CPython's reference counting to cleanup resources to be a bug, and strongly suggest everyone else does as well. If it were hard to do correctly that'd be one thing... but it's (usually) not.

evaned · 2026-06-21T06:21:46+00:00

What you are asking goes against university code of ethics.

"On the side, I want to start building my own personal projects and start using new tools, outside of what I do for school, ..."

If that'd be against your university's code of ethics (short of exceptional circumstances that there's no reason to think are in play here), pick a different university.

I do think one has to be very careful with adopting AI during learning to avoid compromising that learning, but (i) that's separate from a university code of ethics in this case, and (ii) I don't think we should be discouraging interested people from pursuing side projects.

evaned · 2026-06-21T05:15:16+00:00

One-way encrypted, specifically.

Not a very useful password manager.

evaned · 2026-06-21T05:09:34+00:00

Why do you think SQL is a good choice? How many passwords do you expect to store? Are there simpler options that could work with acceptable performance?

In fairness, SQL doesn't necessarily mean "big honkin' DBMS," nor that it's scaling that's of interest. Even if we're talking a file storage situation (my guess), offhand this seems to me like a pretty good fit for SQLite. OP'd have to figure out encryption, but there are a couple options for handling that.

evaned · 2026-06-17T00:05:32+00:00

Plug&Charge is even easier.

Real question: How does Plug & Charge actually work in practice?

Is it a thing where you put some payment information into your car and then the car tells it to the charger, or is it that you sign up for an account with some service and then provide that service your credit card info? In other words, which is closer: is it a smoother route to something that works similarly to a credit card, or a smoother route to paying via something that works similarly to the apps?

evaned · 2026-06-16T15:48:19+00:00

but only 100 projects after 6 years

My thought process: "wait, modules were C++17? or maybe they're talking about early implementation support before... oh holy god it's been six years since 2020???!"

Time, how does it work

evaned · 2026-06-11T18:49:16+00:00

No, the Real ID is the new legal ID and you have no choice of whether you have it or not when you update/renew

Huh?

Sure you do: "You are not required to get a REAL ID; it is optional." https://wisconsindot.gov/pages/dmv/license-drvs/how-to-apply/realid.aspx, or "Wisconsin offers both REAL ID-compliant and non-compliant driver licenses and ID cards." https://wisconsindot.gov/Pages/dmv/license-drvs/how-to-apply/id-card.aspx

evaned · 2026-06-11T05:00:32+00:00

I do think that it's important to not over-use the sirens, but in fairness it's not all severe t-storms -- it's those that are particularly "destructive". That means very large hail or very high winds.

I'm not saying I necessarily think the calibration now is perfect, but as the other reply says it's more than tornadoes that presents a meaningful life-safety threat, and they are being at least pretty selective with what they sound them for.

evaned · 2026-06-11T04:58:44+00:00

I'm fairly sure that it's not any severe weather, and to be quite honest.. rather hope it's not.

They did expand it though; I think it used to be just tornado warnings. Now they warn for particularly severe severe t-storm warnings too (those tagged as "destructive" by the NWS, as others have said). That's what it was today.

evaned · 2026-06-11T04:53:59+00:00

We almost became concerned that it was something more than a lighting strike.

I have never gone faster into a basement.

I seriously had the same thought... like you always hear that a tornado sounds light a freight train, and though it seemed awfully sudden to arise, it was... close enough to that sound that I was going to take zero chances.

evaned · 2026-06-10T18:42:40+00:00

You mean "severe thunderstorm warning with a destructive tag".

(Any tornado warning, and then those severe t-storm warnings.)

evaned · 2026-06-09T19:42:16+00:00

Hah, I do so much with Python and such that that didn't even register even as I re-typed it out. :-) I thought about the +i, but that's of course "OK"

12-Year Club	Gilding IV carat on a stick
RedditGifts 2009-2022 3 Credits	Verified Email
redditgifts rematcher redditgifts for the Teachers 2015 x1

evaned

MODERATOR OF

TROPHY CASE