matt2000

I hadn't seen the network driver comparison before, interesting. Go does really well here, maybe because this is the kind of job is was designed for originally? I'm not sure. For the kinds of things I generally write, this is usually a good way to compare something approximating real world performance: https://www.techempower.com/benchmarks/#section=data-r18&hw=...

C, Java, C# and Go all appear at the top there so it's basically a wash, +/-5%. I still think the main perception of Go as "the fastest option" on places like HN is because people are coming from some of the slower languages (Javascript, Ruby, etc).

Footnote: I don't think there's anything wrong with using a slower language, a lot of them have higher productivity overall. I also just happen to prefer programming in Java, so it's overall the best choice for most jobs for me.

My sense is that most people moving to Go are coming from Node and that explains their excitement about the performance. Not many upsides when you’re already on Java.

Very interesting. If you wouldn't mind sharing some more details: Are you receiving fairly steady order flow now? Where do most of your customers come from?

Thanks!

This is so cool! Using streetview really matters for some reason, it made it totally obvious where the thing was going to appear. Great job.

The basis of this post isn't too sound:

* The "5k% spikes" being discussed here are on a tiny base load. His peak is 6K page views in a day. That's 4 pages a MINUTE. A raspberry pi could handle that. Anything can handle that. There's no load here.

* It's not clear what IPFS is getting him, but it's certainly not performance. Any performance improvements are coming from using the Cloudflare caching proxy, which is basically just using Cloudflare as a CDN. You can get that with a normal website behind Cloudflare with a lot less hassle.

It's fine to check out the implementation details for interest's sake, but let's just be clear that it all could have been done with a $5 VPS.

Given unlimited time, money and importance of the code in question - go for 100% coverage. Otherwise, probably not.

Good point, the multi-AZ RDS feature is a nice way to get most of the resilience upsides without any additional app complexity. You do double your database cost, but that might be worth it.

Just wanted to add a quick note before we get the usual deluge of "you should be running in multiple AZs and regions" posts: These outages are relatively rare and your best decision might just be to accept the tiny amount of downtime and keep your app simple and inexpensive to run.

I of course don't know the tradeoffs involved in running your system, but I know for a lot of my situations the simplicity of single AZ with a straightforward failover option is usually the right tradeoff.

Bad idea: Being dependent on a single company for your salary while also holding mostly that company's stock in your investment portfolio.

Worse idea: Also investing in that same company's highly risky VC fund.

Worst idea: Borrowing money to do so.

Again, I find refactoring tools handle this well, and also this is kind of the point for me - I want to see the effect of type changes.

I hear you, but the current state of affairs in Java (I know this isn't quite Java, but just for illustration) is more like:

  Dictionary<string, KeyValuePair<int, string>> contrivedExample = new Dictionary<>();

Which seems ok to me? And we don't enter the slippery slope of allowing variables without types, and hoping people just use it where appropriate.

Agreed, better to use an IDE to insert the full type of a variable automatically so the code is readable in any environment afterwards.

Inferred types feels like an invention for people who don’t like IDEs, that somehow forces everyone _else_ to use an IDE.

Many IDEs can automatically insert the type of a variable when developing. This seems preferable: have one person do this one action once, rather than every person reading the code in the future having to do work to decode the type.

France is an interesting look at an alternate future where Nuclear was done properly. If world energy production was more like France we'd definitely be in better shape.

There basically _are_ no problems left, it's mainly economic and production volume now.

None of those counter points points really hold up under scrutiny:

1) Renewable power _is_ clean. It is also becoming baseload and dispatachable with the addition of batteries. Battery price is on a reducing price curve similar to solar experienced, during which we heard the following progression of arguments: It's too expensive for anything, it's too expensive to matter, it's too expensive for most regions, it's not a solution for everything, ok it's the cheapest source of power but we'll still need natural gas because... batteries are too expensive for anything! 2) Panel disposal is a TINY problem compared to climate change. Panel disposal is also TINY compared to environmental damage of other energy sources.

Nuclear would have been nice, but it's probably too late for that now, not worth the downsides, and also we don't need it (see battery price curve).

Great idea! Very smart to focus it on building profile pages for Instagram users, then it's a focused use case rather than the general "make a website."

One suggestion: I found the whole term "Insta website" to be more confusing than helpful. I think of Insta as short for Instagram so it confused me to keep seeing it in another context. Honestly, I don't think you even need to define that term. Just focus on the benefits and why the user, as an Instagram user, should want a great page linked on their profile. "Get a profile page like all the top influencers...", "Grow your other social profiles...", etc.

Just a suggestion, hope the idea works out!

The price goes down over the first 3 years as well. Not sure why they do that exactly, but for a long time user like myself I'm happy they do!

Just a reminder of the key things related to Starlink (since I had to go look them up - https://en.wikipedia.org/wiki/Starlink_(satellite_constellat...):

* Total deployed size will be ~12K satellites and take a decade or so. Will be operational in a reduced capacity as early as next year.

* Since they're in low earth orbit, latency could be in the 35ms range.

Would anyone mind sharing what time series DB they use in production, and what for? I'm assuming most are used for metrics in addition to a standard SQL database, but interested to find out if that's accurate. Thanks!

My guess is that at 5min resolution (288 data points per day), you're probably just better off going stock SQL. My understanding is that time series DBs start getting useful at higher write loads that standard SQL DBs aren't necessarily optimized for, and where you might want things like data to coalesce into larger timeframes to save storage, etc. I'm not an expert though, just what I've seen from my somewhat limited experience.

Looks like fuel costs are really low, but maintenance and replacement component cost might be pretty significant: https://www.sciencedirect.com/science/article/pii/S036054421...

I'm both excited and skeptical. There was a similar demo in 2016 and then repeated claims that full self driving ("coast to coast with no interventions") was less than a year away. How is this different? Apparently people at the event were taken on demo rides and it was very impressive. However, Tesla's current system has several notable issues like crashing into stationary vehicles at highway speeds. So what's the truth here? Very exciting if this is the breakthrough we've been waiting for, but I'm skeptical of all claims until released into the wild and shown to be generally true.

Humans design technology, a technological failure is a human failure.

I've used Scaleway for one thing where I needed lots of cores and latency didn't matter, but I'm not sure I'd use them for much more. Heard a bunch of questionable things about their networking too, how has your experience been so far?

Would you call it a managed database, i.e. does it come with continuous backups and things like that?

Very cool, congrats on getting to this point. I have a few questions as a long time heroku user:

- Can you scale up to more app server instances? - Where are your servers running? Based on location and the pricing progression, I'm guessing Scaleway? - How are logs handled?

Thanks!

I think it actually uses "Cheerpj"? Or at least it's listed as one of the demos: https://www.leaningtech.com/cheerpj/demos/

The decreases in battery cost in this report are pretty spectacular, but it's missing comparisons to costs for traditional generation. As best as I can tell from https://www.eia.gov/outlooks/aeo/pdf/electricity_generation.... - the LCOE for gas generation is around $40/MWh. So this article's cost of $187/MWh for batteries is still a lot higher, but the battery cost has dropped 35% in one year so it could get there soon. What I'm still not sure about is if you need to include the LCOE of the original generation method in the cost of the battery system? In that case the total LCOE for say wind+battery would be ~$210.

Strongly recommend Cloudflare in combination with some uptime monitoring service. Cloudflare gives you so many options on ways to mitigate attacks, and you get CDN and other services for free. Pretty great.

The path to vehicle electrification might not be that long: https://about.bnef.com/electric-vehicle-outlook/

Also, it's worth making the distinction between vehicles and vehicle miles travelled. We might not replace all the cars right away, but the majority of the miles travelled might convert pretty quickly if they're done via TCO sensitive fleet vehicles (Uber, Lyft, etc) and/or 2nd car commuter vehicles.