asdkhadsj

It depends on the music for me. Music really tones in my moods. I use it as a tool to motivate my life, for whatever I'm aiming at.

This applies to programming for me because sometimes I need music that promotes creative thinking. Sometimes research. And sometimes, my favorite, hammering out the code because I have a rock solid idea on implementation and trajectory.

The wrong music in any one of those steps is actively harmful to my work. The right music promotes it. Silence on the other hand is weirdly deafening to me, usually. Sometimes I have to pause my music and talk myself through a problem, and sometimes in doing that I forget to turn the music back on. I frequently find myself 1 hour later, super tense in the shoulders and all around stiff. It's a weird and stressful state. The silence is too loud.

As a sidenote, I've been thinking about instituting an internal styling guide to discourage `unwrap()` in your scenario, in favor of `expect("impossibly missing")` or etc.

The message helps a bit more, and I also want to avoid debug unwraps that were forgotten about.

Though, the more I think about it the more a macro makes sense to me, purely for code search. If we used a macro, something like `impossible!(streams.pop())` then I can code search for `.unwrap` and `.expect`.

Hmm

Eh, maybe I was primed, but it got me too for a second. I scanned for the usernames wondering what might be the issue, and then I noticed there was two users with similar names, k_12 and k_8 - that must be the confusion!

.. nope, I'm just dumb too. Hah :)

That's fair. It never occurred to me honestly, but it's reasonable - especially since I don't think humans can reliably make `down.sql`

> How about a facility to roll back a migration (doesn't seem like it?)

Ack, I assumed it was building the rollback based on an understanding of what was applied. If it can't rollback (unconfirmed yet), that is a problem. Bummer

Indeed, that's why I wanted to migrate from it

Glad to see this. Recently I was debating using Keybase for chat at home over Telegram. For now I guess I'll need to use something else.

edit: oh never mind, looks like they started to address it: https://keybase.io/blog/dealing-with-spam

That may be true for some, but it's not true for me - currently.

Ie, if I could get a DB/FS + PaaS for $5/m I'd use it in a heartbeat. If I run into a wall where I need to manually tweak some fine detail, I can always fall back to normal deployments, right?

PaaS in concept fits exactly what many of us seek. Deploying apps without managing ops. Just because it's not infinitely powerful doesn't mean it's a reason no one would use a PaaS. PaaS fits a very real use case.

In my somewhat edge case though, hobby/side projects, I can't pay much for them. So I manage the ops myself currently because I can save money, but if Heroku was just a bit more cheap I'd use them.

No, but that's mainly because I still have to manage the server running Dokku I believe?

edit: For context what I was already using was manual docker on a DO box. While I recognized that Dokku would make it more seamless and easier, my issue was managing and securing the DO VM itself. I didn't see how Dokku would help that scenario

That.. is really impressive! Had no idea about this, thanks!

For a well rounded review, can you or anyone comment on similar offerings with competitors? I was not familiar with per-request containers, but it sounds like exactly what I wanted.

Thoughts?

I can't wait for PaaS prices to drop. I know they'll always be relatively expensive, but I'm primarily a dev (not ops) and I don't have the time nor desire to manage my own servers securely.

Heroku lately has seemed a tempting offer, assuming I can run my apps on it (Rust based), but at $7/m for little side projects it felt.. expensive for a no user side project. They can add up. A $5/m DO box can host quite a few apps in containers, by comparison.

Perhaps Serverless would be a great playground for low/no traffic apps, but I've not gotten into serverless much.

Is there a better solution though? I agree that's a super real thing, but having no security at all (as is the case now, basically) is infinitely worse.

We would need to change some things, but I'd love to know if some random lib I'm using is trying to do things my application shouldn't. Or if something I installed, say Docker, is trying to access my photos or ssh keys.

> Unfortunately for things like python the permission is granted to the Terminal app so once given, all programs running under the terminal inherit the permissions.

Would Python permissions even be enough though? All it takes is one legitimate Python application wanting your Photos (lets say some Python photo manager app you wrote) and now all Python libraries get access.

Unfortunately, I think Apple's direction may be correct. It feels hugely inconvenient, but an end goal of all processes being signed and explicitly allowed certain things seems useful.

At the very least, Python should perhaps never get access to anything beyond the devving folder. Then any real use of Python applications would have to be properly baked out into processes where the OS can manage permissions for. This goes for all languages, Python was just an example here.

This is all off the top of my head, so I could be way off base. But it seems logical to me in the moment.

As a Rust lover, it can be quite the hill to climb when you first start looking at it. Closures really weirded me out when I first started.

Though, you may also be referring to the "made up language" powered by the Macros. I agree that can be a bit much, but it's in my view no more distracting than React's JSX. Some people hate JSX, and I imagine they would hate this as well.

I think there's other types of compulsive people too. I'm not, in my view, a compulsive puzzle solver. Rather, I'm obsessive about understanding elegant solutions to complex problems. Usually I define elegance in different ways, but nevertheless that's the thing I most enjoy.

So puzzles by themselves don't often hook me too much. Especially if the puzzle itself has 1 way to solve it. But I'll spend days obsessing, losing sleep, forgetting to eat and etc all because I "feel" a problem has a more clean solution.

Though, I'm probably not a hacker in this sense.. hmm. /shrug

I think I agree with you, BUT I will say that it's a problem I just don't have with JSON.

I think it's because JSON is inherently smaller, and the spec primarily focuses on basic types that handle data.

With JSON I can write idiomatic code, in any language, and the translation to and from my code is correct. I don't need to abstract away my JSON code for arbitrary reasons, it works.

I'm not sure why that is TBH, I just know that it's a restriction of Protobuf I don't find myself running into with JSON.

I go over it in a bit more detail here: https://news.ycombinator.com/item?id=21621592

But in short, Protobuf is inherently a language of its own. Like JSON or etc. But it's feature rich enough that it can cause a fair number of incompatibilities between a language's preferred style or usage of features.

Where the incompatibility shows up depends on the language. I found it to be very different between Rust and Go, for example.

PREFIX: It's been ~1.5years since I've used Protobuf and Go together, so forgive my memory.

Sure, take Go for example. Protobuf to Go works well, but there are some features of the Protobuf language that just don't exist in Go. Enums, for example. While Go does have constructs that are similar to Enums, they're just different enough to make it a bit weird.

This basic problem gets worse when you try to use it though. The `One of` construct, for example, is sort of impossible in Go. Iirc the Go implementation had to use runtime type checking to give some resemblance to the Protobuf spec.

Rust (which I focus on now) was far better with Protobufs. As far as I remember, there wasn't much of Protobufs that broke idiomatic Rust. However, there was plenty of idiomatic Rust that broke Protobufs iirc. Things like complex data structures behind enum variants. Enum variants as structs, tuple values, etc. iirc it was bad enough that I usually used an abstraction library to write my idiomatic data structures and convert to/from the Protobuf structs.

Which, is how I left it all together. I realized I had a ton of glue code trying to make up for the incompatibilities in Protobufs + (Go|Rust), such that it would just be easier to drop it - at least as far as my code is concerned.

We now struggle with documentation, something Protobuf did excellently, but at least the code smell is gone.

Man, I wanted to love gRPC. The disconnect between Protobufs and languages just felt too great though. You could do some weird things that just made every language feel, to some degree, non-idiomatic.

I switched to Twirp at one point to retain the simplicity of RPC + Protobuf, but avoid some of the complexity we didn't need via gRPC... but even that suffered, of course, from the Protobuf problem.

Finally I'm back to plain HTTP and JSON. We don't worry too much about REST fundamentals, and honestly we're more like an ad-hoc (JSON) RPC over HTTP, but it's simple.

The only problem is documentation. The one thing that I found perfect with Protobuf. Seems really hard to have everything here.

Are you familiar with how costly backtrace is?

I fear bubbling an error up and repeatedly adding a stack trace or some junk like that. Admittedly I have not looked too much into Backtrace, but I hope my concern makes sense.

We're using Rust for general purpose APIs. What would normally be written in Python or Go, for us. We just prefer it. We're also using it for a couple memory/generic intensive applications that were previously written in Go, but the lack of Generics made some API design awkward.

I use it for all my personal projects as well. Which are basically the same types of things I wrote in Go. Though, I also am experimenting with WASM DOM UIs, something I've not yet used in Go.

> And some application developers prefer having an "I don't care, just give me the backtrace" error wrapper for everything, to speed up the development and not spend time on micro-managing error types.

That's me tbh. I actually love Rust's error story atm, I always use an Error enum and I have made it do everything I want.. except one thing: Low (no?) cost backtraces.

My error enums give me all the API-level specifics I want, but often I make the variants grouped by general code area. It's guided by my program flow, not debug introspection. So if I don't need to branch a codepath from an error object, it typically just goes into a single variant and I shove some message in there.

What I'd love is to be able to easily and quickly just bake backtraces into this "non-program flow defining type". Bonus points if it could be done at compile time.

I've thought about using a macro at error creation time to make it a compile-time poor mans backtrace, but I'm unsure if just one level of stack trace is all that beneficial.

Either way I know I want something that's no more costly than:

    foreign_err.map(|foreign_err| MyError::Dump(format!("some description: {}", foreign_err)))

edit: I should add, internally my perspective is coming from Go, so wrapping repeatedly in strings is fairly welcome to me. Just adding some low-cost default context to this would be a huge help.

I'm not a car or truck person.. so forgive the ignorance.. but is it rear wheel only? The `Drivetrain: REAR-WHEEL DRIVE` section has me perplexed for a number of reasons.

1. I thought Teslas where all wheel? Ie, the nature of how they work is such that each wheel was a motor. Is that not the case for this one?

2. Isn't all-wheel a valuable offering? This doesn't seem to be an off-road focused vehicle.. but nevertheless I personally value all wheel. Am I wrong in this?

I find this weird. I can't afford it anyway, BUT, I have often joked that I need a small Tesla truck to replace my Prius. However, strangely nothing about this interests me. Even if I had the money.

Sidenote,

I've been focusing on a lofty personal project for some problems I'm solving in my life, and hope to aid in solving for others. My project is primarily focused on self-hosting, but I would like to offer hosting for those who do not want to host.

Sourcehut is my inspiration for how to handle a FOSS + Hosted project. The financial reporting, UI design, approach to development, all of it is stellar.

I don't currently use Sourcehut but it is a huge inspiration to me on how I want to run my own non-profit aspirations. Thank you Drew. Really.

What makes the (lack of a) dynamic DNS a safety issue?

My concern with the IP changing is if I was on vacation and my IP changes, I'd have no clue how to get back to it.

Yea I was thinking something like that. At first I thought SSH would be plenty secure on its own, but then I thought what if I'm devving and want to see the server page? Or maybe a DB hosted on the machine? Etc etc.

Though I think I'd use Wireguard, but still. Some type of easy to manage VPN, with a Dynamic IP domain thing.

Any recommendations on the dynamic domain? Self hosting something might be neat

That's awesome, think I might get that and stash it in my car.

Now all I'd need is to figure out how I wanted access to my env. Eg, being able to ssh into a home machine and then work in emergencies seems valuable. But, that would involve exposing my machine. Hmm

Sure, and I'd love to see prices for those too. $200/m I doubt, though. Purely search though, nothing else from Google (I pay for my email/etc)

To say though that Google has to get a piece of the $200/m that some blogger makes assumes of course that Google is the ad provider. Not sure, but it seems like a weak argument.

I wish I could start seeing the real no-ads costs here.

Yea, but in my comment I didn't care about Google. We were talking about money going directly to content providers, to compensate for the fact that they don't make ad money off of me.