HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nathants
libaws
Go2022–2025
nathants / libaws

libaws

just ship on aws

DevOps & Cloud
Explore on GitHubRead Hacker News discussions
4Distinct people
30Mentions
0Explicit recommenders
453GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

just ship on aws

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year30 dated mentions

Observed mentions: 2022-05-19 22:27:36 UTC to 2025-04-08 06:56:13 UTC.

0510152022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 17 mentions; 4 submissions, 13 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC17413
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC909
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC110

What Hacker News says

17 sources
nathants·Oct 19, 2022
build and scale systems with artificial load on aws! scaling the load testing will be just as interesting as scaling the system under test. start with low bottlenecks, ie a cluster of c6i.large ec2 spot. how fast can you do this? have fast can you scale that? ec2 and s3 is all you need to build anything. use ec2 spot, avoid network egress, avoid cross region/zone traffic, create and destroy ec2 instances as needed instead of letting them sit idle. you could grow system scaling intution for the price of your streaming subscriptions. start with something like this: https://github.com/nathants/libaws/tree/master/examples/comp... maybe mess around with public datasets on aws, just make sure to be in the correct region to avoid data egress. welcome systems, friend. stay a while and contemplate. one accurate measurement is worth a thousand expe
Read the rest
rt opinions. scaling is fun!
In Ask HN: How to get more experience with system design questions (esp scaling)?
nathants·Sep 9, 2022
on aws as scale to zero services. lambda, dynamo, s3, and ephemeral ec2 spot. when egress bandwidth is needed i use cloudflare workers + r2 just like i would use s3 presigned urls. services with no usage should have no cost. services with usage should bill based on usage. typically i start from a full project template[1][2]. sometimes i start from scratch[3]. 1. https://github.com/nathants/aws-gocljs 2. https://github.com/nathants/aws-exec 3. https://github.com/nathants/libaws
In Ask HN: How do you deploy your weekend project in 2022?
nathants·Sep 6, 2022
aws has too many knobs, presumably to satisfy the union of the needs of all the enterprise customers. that said, lambda+s3+dynamodb+ec2 are pretty good once you tape over all the knobs that aren't needed. i work with them like this[1]. these days i build on aws and r2. aws for the nuts and bolts, r2 for high bandwidth egress. it's a perfect match. 1. https://github.com/nathants/libaws
In Static site hosting hurdles
nathants·Jul 18, 2022
i dragged my feet on go for a long time. i also thought that skipping go and moving to rust was the play. a few years later, i still write python often, but i don’t build systems with it. python i now use like bash, to glue things together and automate random things. it’s a fantastic language and i will never drop it. the verbosity of go is the biggest hurdle for a pythonista. the thought of giving up context managers, decorators, iterators, comprehensions, exceptions, coroutines, it’s unthinkable. in comparison go is ugly. your aesthetic mind screams in protest. write go full time. dive in. as months pass, not only will those aesthetic objections fade, your mental model from python cleanly transforms to go. go is what mypy tried to be. the cost was aesthetic changes. the benefit is worth it. the zen of python says if it’s easy to explain
Read the rest
it might be a good idea. this is go, and it is. i rebuilt a reasonably sized project from python[1] to go[2] over the last few years. i also have a system that i maintain both python[3] and go[4] implementations for, sharing a test suite in python. squint at the implementations. consciously ignore aesthetic objections. they are basically the same, not very different from a python codebase with and without type annotations. go, like python, is fantastic. use both in whatever amount works for you. don’t read about them, build with them. you won’t regret it. 1. https://github.com/nathants/cli-aws/tree/bb78e529e7d1d3f95ac... 2. https://github.com/nathants/libaws 3. https://github.com/nathants/s4/tree/python 4. https://github.com/nathants/s4
In Learning Go as a Python Developer: The Good and the Bad
nathants·Jul 3, 2022
this is a good idea, but difficult to nail in scope and multi-lang support. i’ve made similar attempts[1,2]. tbh if this had go support i’d probably try it today. json, yaml et al are ways to declare literal data. this is good. they are fine. the issues always come from what the data is used for. nailing your schema, making your data structures as simple as they can be and no simpler, this is where the engineering happens. this is the hard part. literally all that matters. not validating arbitrary data inputs is obviously a bad idea. whether you validate them via a high level library or tediously by hand[3] isn’t very important. what is important is that the data structures are sane, simple, and stable. if they are easy to describe, they might be a good idea. if the approach the complexity of general purpose pl, they probably aren’t. most
Read the rest
literal data schemas are too broadly scoped. too general. github actions, other ci, k8s, etc. they have too many knobs, too many permutations. this is not a feature, it is a failure of design. good schema validation won’t fix broken design. it’s unrelated. 1. https://github.com/nathants/py-schema 2. https://github.com/nathants/clj-schema 3. https://github.com/nathants/libaws/blob/ae48040911bf2c0554da...
In StrictYAML
nathants·Jun 10, 2022
on my own site, as static files embedded in a lambda zip like this: https://github.com/nathants/libaws/tree/master/examples/simp... will probably switch to cloudflare+r2 soon since egress is cheaper. r2 is fantastic. here is an mp4 screen recording uploaded adhoc yesterday. a friend was trying to setup tinysnitch and was wondering what prompts looked like when visiting netflix: https://r2.nathants.workers.dev/fcd5ca7a-3d25-4912-9404-2bc0... site: https://nathants.com
In Ask HN: Where do you post your writing?
flurie·Jun 10, 2022
Increasingly it seems like people think there is a need for tools that bridge the gap between simple and complicated IaC. I think this is a better idea than a bespoke cli tool that does something similar[1], but I don't think it escapes the core problems that tool has, which are the same problems that people and organizations encounter with other complicated infrastructure/deployment tooling: getting good at these things is a time sink, and shortcuts that magic away some of the pain also magic away the ability to learn. [1] https://github.com/nathants/libaws
In Show HN: Terragen.dev – Automagically Generate Terraform for AWS
nathants·May 28, 2022
amen! as another commenter here rightly put: state or idempotency, pick one. hello? how is this even a question? i have a hard time believing that idempotent infrastructure mutations are not the right move almost always. shameless plug[1], i’ve been exploring an aws specific approach to infrastructure that is stateless and idempotent for exactly these reason. slow, finicky, stateful deploys are about as awful as it gets. add a pinch of lowest common denominator among all providers, and that’s a tough pill to swallow. there’s got to be another way, aws should be fun! 1. https://github.com/nathants/libaws
In Terraform should have remained stateless
NathanKP·May 24, 2022
Some feedback on this idea from someone who works at AWS and has worked on similar tools to make AWS easier, such as AWS Copilot (https://aws.amazon.com/blogs/containers/introducing-aws-copi...): The hard part isn't making AWS easier, it is making a tool which is both easy and flexible enough that a user can do what they need (within reason), then outgrow your tool and move on. In specific any tool based abstraction has the downside that if the only way to interact with your infrastructure is through the tool then you severely limit the options for a user to make customizations. AWS will add features faster than you can keep up, and there will always be someone who can't use your tool unless you have feature X, Y, and Z. At that point you can either add more and more features until your tool becomes as complex to use as all of AWS itself,
Read the rest
or you can draw a line in the sand and say "you have outgrown my tool, it is time to move on". When they reach that point you should try to make it easy for them to avoid having to recreate everything from scratch themselves. For AWS Copilot we tackled this problem in part by adding a "copilot svc package" command which spits out a full CloudFormation stack for your application and all its infrastructure, so that you don't have to restart from scratch if you decide you have outgrown Copilot. Copilot will help you deploy simple Docker based container applications quickly and easily, but then if you have more complex needs you can "graduate" on to the next experience by exporting things up into a stable, productionized CloudFormation template that lets you customize the full range of AWS settings and resources to your hearts content. I think your tooling will need something similar. The "outgrowing" section (https://github.com/nathants/libaws#outgrowing) is a bit weak right now, and that's what you need to really nail down for people to have the trust to start adopting a tool for serious usage. They need to know that once they outgrow the tool they will have a viable path that won't be a huge headache. Otherwise I like your ideas here, and I think the YAML based DSL here is a fascinating abstraction of many common, simple use cases. Great job!
In Libaws: A simpler way to declare AWS infrastructure

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.