idubrov · HackerTrans

4 yıl öncediscuss

Wiring 240V is (typically) not an issue, as it is standard (in the US) to get 240V from the transformer to the house. The devil is in the details: what current would you wire it for, what receptacle are you going to use and what are you going to plug there.

idubrov

4 yıl öncediscuss

Yeah, it shows that I have zero knowledge about commercial appliances. I guess, I wouldn't be surprised if they routinely use 20A plugs / receptacles. Would make sense. Maybe, hospital equipment, too?

idubrov

4 yıl öncediscuss

The problem with 240V is that there are few NEMA standards used is USA (although , they look bulky and are kind of unsafe around the kids.

Which is not a problem for dedicated circuits (you could wire receptacle just for this specific dryer / hot tub / RV / whatever, plug it and never remove), but would be a bigger problem if 240V is shared between appliances.

I think, NEMA 6-15 / NEMA 6-20 would be the best (they look very similar to standard 120V outlets; they have tamper resistance; 15A or even 20A should be plenty enough), but nobody wires them.

Also, there are other minor differences like:

1. 50Hz in Europe vs 60Hz in USA. 2. The voltage between ground and "power" lines would be different. In Europe it would be 240v between line and ground and 0V between neutral in ground, in USA it would be 120V between ground and both power connectors, due to how 240V is typically delivered to single-family homes in USA (split phase). Should not make much difference (you are not supposed to have any current to ground anyway, and any short-circuit should trigger the circuit breaker), but maybe it will affect safety somehow? 3. Seems like in some cases in USA you can get 208V instead of 240V (and Europe is nominally 230V).

idubrov

4 yıl öncediscuss

Right, there are code compliant solutions. I was just musing over an idea of having 240V "everywhere" (including inside the house in every room, having 240V for special needs is, of course, a solved problem).

14-50R is not what I would use in that case, they are bulky, unsightly and don't offer tamper resistance.

6-20R / 6-15R have variants that are tamper resistant, and they look like regular outlets.

"20A should be enough for everything".

We used to have 2.5-3kW kettles before we moved to US, which would require 20-25A (although, I don't think the math is that simple -- circuit breakers don't trip on "exactly 20A").

Also, the issue with 20A receptacles is that, again, I have never seen 20A plugs (NEMA 5-20P) on appliances (it has neutral connector "flat" rather than vertical). Which is understandable, why make them if nobody has 20A receptacles anyway. There is a requirement to have two 20A branches in a kitchen, but commonly they are wired to 15A receptacles.

idubrov

4 yıl öncediscuss

(everything below assumes US and NEC / local electrical codes)

I don't think code prohibits it, but in my (not very educated) opinion, you might get into some gray territory if you try install them everywhere.

There are some safety related provisions which are mandatory for regular 120V (GFCI and/or AFCI), but I don't think they are required for 240V circuits. Building inspectors might have questions if you install these outlets everywhere. Although, again, I don't remember any limitation of where you can have them.

Another issue is the type of the receptacle. Apparently, Leviton makes receptacle that might be allowed in US and is combination of regular 120V plus European style 240V. However, it is only limited to 2.5A, which is very little (I think, this receptacle is primarily designed for hotels / shared spaces where you only want to charge your devices). Also, I don't think it has ground for 240V.

Probably, the best would be to use US 15A/20A receptacles (NEMA 6-15 / NEMA 6-20), which look very similar to the regular 120V ones (the difference is blades are horizontal).

However, I've never seen any actual plug using them (even though I did install these 240V in my garage, expecting some 240V equipment). But you can rewire plugs on your "imported" equipment / appliances.

There are also some interesting differences of the supply: in US it is typically split phase 120V+120V=240V, but sometimes (according to the internet) it could be 3 phase 120V with 208V between phases; in some parts of the world, it would be 3 phase 230V with 400V between the phases. This probably would cause some differences in how grounding works, might affect safety.

But yeah, generally, 240V should not be a problem. Power-hungry equipment (water heater, range, electrical dryer, EV chargers) -- they all typically use 240V already.

idubrov

4 yıl öncediscuss

It's the configuration complexity clock!

http://mikehadlow.blogspot.com/2012/05/configuration-complex...

idubrov

5 yıl öncediscuss

Interesting.

When I was doing my research on ULPower engines (which can burn 100LL, but they would prefer non-leaded), there were very few airports who offered unleaded fuel (UL94). I think, San Carlos / KSQL was the only one I found?

I wonder what KRHV closure would mean for unleaded fuel? So everybody would just switch back to 100LL? How is that supposed to help?

Wouldn't be more practical (from the point of lead pollution) to enforce non-leaded fuels in those small airports instead? My cursory research shows that lot (?) of these light planes (and, perhaps, the majority of the trainer/weekend hobby aircrafts) would happily burn non-leaded fuel (UL94, for instance), with corresponding STC.

idubrov

5 yıl öncediscuss

>A common way to solve that problem is usually to use references instead of cloning.

Right. I think, we ended up with having everything from the list:

1. String 2. &str 3. Cow<str> 4. Arc<str>, for interned strings (thin Arc would be even better & there is probably a crate for this) 5. Something like owning_ref::ArcRef<Owner, str> 6. One-off tricks where you actually need to construct a new string, but don't want to really construct it (for example, for hash lookup).

#5 I think is undervalued, actually; it's amazing for "enterprise" kind of stuff where you have large trees of data you need to pass around & you don't want to use straight borrowing (like &'a Whatever) because lifetimes are too infectious. And you don't want to use Arc at every corner (like, say, Java would do, not quite, but in semantics).

My problem, though, was to explain all the nuances given that they usually have nothing to do with the "business" part of the problem somebody was solving.

idubrov

5 yıl öncediscuss

I have some extensive (self-assesment :) ) experience building this kind of application, and my answer would be "no, but maybe" (I was one of the first engineers & architect on our zero to ~500k codebase).

Some of the arbitrary, random things I've learned:

1. Given how nice and powerful language is, Rust works relatively well with less experienced engineers. Potentially. You can build very nice APIs which are straightforward to use.

If you can stay in this territory, everything is great.

However, there are some hard walls in Rust which are really difficult to jump over. And once you hit them, you really need somebody who understands Rust really really well and is capable of working around those issues.

2. It was quite hard to find the right balance between engineering time, compilation/linking time, safety, ease of use, performance, etc. Might be my personal biases, but I had to make some questionable decisions to keep compilation times / turnaround times at bay (like, unsound plugin system, custom serialization framework or test framework using nightly Rust features).

3. The type system is really, really nice. This alone compensates for a lot of things.

4. Ecosystem? Simply amazing. High quality libraries, documentation and everything.

5. Ecosystem again? Lots of things are still missing.

6. Performance? I'm 90% trolling here, but my experience was that Rust is not "blazing fast" by default. Not for "enterprise" software. You have to do some legwork sometimes. I've built some simple tool to do certain transformation between JSON and XML, and out of gate it was ~2x slower than Java equivalent (yes, with release build). Turned out, strings are not that cheap to clone if all you have is a bunch of strings. I did make it like 5x times faster than Java in the end, but it did require some weird tricks (like forcing hash map to look for a "derived" key than I give it).

There were some other cases where performance was reduced by simple things (like, having "heavy" Result vs having error variant boxed).

I think, this is "easily" counteracted by adopted practices and libraries (optimized error types, for instance), some standard patterns (like don't be afraid of Arc, they are better than to move huge data chunks around), maybe, good profilers as well.

This is probably also my biases talking here, frankly, I don't think it mattered at all (performance was killed by database, as is very common with enterprise systems). Also, in the end, it was fast (outside of database woes).

7. Overall, I find Rust very exciting language to work with, which was a big driver (but that doesn't necessarily scale -- you'll have to have some answer prepared when less experienced engineers will ask you "but why can't I do like I did in Typescript in those trivial 500 lines of code").

Would I do it again? Probably, but with understanding that whoever pays for it, might be paying for my "fun" on top of the product they are getting. Which is not necessarily a bad thing -- "fun" is also a factor in attraction and retention of engineers.

I'm also not going to lean into the "dark side". Like, if all you care is to get some half-broken whatever out as quick as possible, Rust might not be the right choice. It makes you think about "right or wrong" a lot, imo.

comments