The hybrid server render, then hydration step is too magical for my liking. There's a bunch going on in there that would be very difficult to debug, if some mysterious error at this stage of the app were to present itself. I prefer either wholly SPA or serverside, can debug and understand the whole thing.
His cost is probably around $4k per device, which gives him $16k to play with.
His gross profit is probably about $12k per.
Shipping is probably about $4k/container. It used to be $2k for a 40-foot before the pandemic.
He also has to front the money and carry the inventory, which is the real problem. The big manufacturers finance their equipment, which he probably can't do. So he needs to pay cash up front. Maybe he needs to sell 4 to cover costs. But then he needs to buy the next shipment, which'll eat up his cash flow.
FYI, this is the problem with inventory financing (or lack thereof): you need money to buy and carry the inventory. If you're not careful you'll lose money on the float.
He talks about some of the extras he did in the post. Assembly, testing and pre-purchase inspections. I assume some of the markup will be removed when others enter the niche.
You can also find some deals on branded equipment on gov auction sites. People are buying lots there, refurbishing when required and reselling for similar markups.
All of the options require a bit of legwork and elbow grease.
Having the combination of capital to buy an entire shipping container of these and also put in the months of work to sell them for a $60k profit seems like an uncommon combination. Like I’d personally find it super cool but I don’t have $100k in cash to gamble on this
Because all the BS rent seeking parties you have to deal with as part of international shipping will make that $6k excavator 12-15k. A lot of costs are fixed per shipment hence buying container fulls and reselling.
And the Alibaba importer is going to care a lot more about satisfying a potentially repeat $100k importer over a one time $5k buyer, and when you purchase large orders like this you can set quality standards for your products and the seller is on the hook if the products do not match the listed requirements.
Basically, you're paying more but they're taking all of the hassle and worry and a large part of the risk out of the operation for their cut and you're not paying much more than you otherwise would for the service.
Haven't written C# for 8 years, but Visual Studio used to be dog slow. But that's the only criticism I can think of, love the language. I remember when ReactiveX came out, C# became close to unbeatable at that point.
I'm more extreme, I dislike all dark mode, including code. Shreds my eyes, no idea why. Have tried a zillion themes, just can't be one of the cool kids.
Off the top of my head, memory safety challenges for junior Haskellers (laziness footguns), State monad being fundamentally flawed: there is an inability to get at and log your application state just before a crash, bloated tooling, GHC frequently breaking existing code. Laziness and monadic code makes debugging painfully difficult.
I acknowledge that those things can be challenging, however I'd like to respond to some of the specific issues:
- Space leaks due to laziness are a solved problem. I explain the technique to solve it at: https://h2.jaguarpaw.co.uk/posts/make-invalid-laziness-unrep... This technique has not completely percolated throughout the community, but I am confident that it does actually resolve the "laziness causes space leaks issue"
- Flawed state monad: well, you point out the analysis of its flaws from the effectful documentation. That's correct. The solution is: just use effectful (or another similar effect system. I recommend my own: Bluefin)
- GHC breakage: I've been keeping an inventory of breakage caused by new GHC versions, since GHC 9.8: https://github.com/tomjaguarpaw/tilapia/ There has been very little! The Haskell Foundation Stability Working Group has had a massive effect in removing breakage from the ecosystem.
- Laziness and monadic code makes debugging painfully difficult: I mean, sort of, but if you're using monadic code in the style of a decent effect system like effectful or Bluefin this is a non-problem. It's hardly different from programming in, say, Python from the point of view of introducing debugging printfs or logging statements.
Thanks, I've followed along with a lot of your posting on the Haskell discourse. One thing regarding this matter:
>well, you point out the analysis of its flaws from the effectful documentation. That's correct.
Thinking deeper about this, that there is essentially no way to fix this issue with StateT, because of the type choice, the monad, the composability requirement, all conspiring together to not be undone, does that signal something deeper that is wrong with the flexibility of Haskell, that we can progressively paint ourselves into a corner like this. Could it not happen again, but with another late breaking requirement, for effectful, or bluefin?
> I've followed along with a lot of your posting on the Haskell discourse
Ah, that's great to know, thanks. It's rarely clear to me whether people read or are interested in what I say!
Well, yes, in principle even a design that is perfect according to some spec could be completely wrong if the spec needs to change. and impossible to tweak to match the new spec. This is true of any language or any system. This raises a few important questions:
1. How easy does a language make it to "unpaint" yourself from a corner?
In Haskell it's easier than in any other language I've experienced, due to its legendary refactoring experience. For example, if you "incorrectly" used the State monad and got stuck, you can wrap it up in an abstract type, change all the use sites, check that it still compiles and passes the tests, then change the definition to use new "uncornered" implementation, again check it compiles and passes the tests, then unwrap the abstract type (if you like, this stage is probably less important), then add the new feature supported by the new implementation.
2. How likely is it to paint yourself into a corner in the first place?
In Haskell, again, less likely than any other language I've experienced, because the constructs are so general. There is far more opportunity to tweak a design when you have general constructs to work with. (That said, I've met many Haskell behemoths that couldn't be easily tweaked so, particularly contorted type class hierarchies. I recommend not designing those.)
3. Why won't effectful or Bluefin lead to "corners"?
Because they're just Haskell's IO, wrapped up in a type system that gives fine-grained control over effect tracking. Anything you can do in Bluefin and effectful you can do in IO, and vice versa. So to really paint yourself into a corner with IO-based effect systems it would have to be something that you can't do in IO either, and at that point we're talking about something that can't be done in Haskell at all. So there's no real downside to using IO-based effect systems in that regard.
Basically StateT uses Either to model either the application state or an error. So if your application throws, you lose the current state forever. They sort of painted themselves into a corner with this choice of type, there's no real way out now.
I agree loosely with what haskman above says about creating relatively bug free applications, the guard rails are so robust. But those same guard rails mean you can paint yourself into a corner that it is harder to get out of without imperative state, case in point above.
Okay, might be definitional, but when I think of 'first class', I think of something baked in to the language. So in Haskell's case, in the Prelude I suppose.
That's kind of the opposite of what functional programmers mean by "first class", or at least orthogonal. "Functions are first class" means that they don't have any special treatment, relative to other entities. They're not really a special "built-in" thing. You can just pass them around and operate on them like an other sorts of values.
reply