throwaway2016a

To be fair I wasn't agreeing with the "API in 20 minutes approach" I was only pointing out the contrast between that and something like this.

As I tried to allude too, AI written APIs often have security, performance, maintainability and a whole slew of other issues.

But at the same time, I think "blank video on your phone for 20 minutes" is a bit of a stretch. These AI generated APIs have problems for certain but they are working software and in many cases better working software than a non-coder or junior engineer could have written in a much longer time.

And while I don't like the idea of tons of insecure poorly architected APIs being out there, the realty is, people are using AI generated APIs in the real-world right now, it's not hypothetical.

> OK Moonwalk has a great vision, but how do we actually make it a real spec?

I'm not sure the article really succeeds if that was the goal. I suspect that there might be some aspects of the discussion that are taking place that are missing from the article making it a little difficult for someone who wasn't in those discussions to connect the dots.

Don't get me wrong, I think the article had some useful pieces in it, I just think if that was the goal of the article it could possibly use some additional framing for people who don't have the full context.

With that said, I really appreciate transparency into the thought process!

I find it striking that in the same day I saw a video about how someone "Made an API in 20 minutes with one prompt" and this. The two approaches seem very divergent. One that is almost cavalier about things like security, standards, etc and another that is (almost) over engineered.

One observation, is that I there are two trains of thought. Using OAD (Open API Descriptions) as a source of truth and generating code from there or treating OAD as an artifact that comes out of some other tools.

I personally see OpenAPI as kind of a glue that can allow different tooling to be able to speak the same language.

Overall I found the linked Moonwalk[1] document to be more interesting. But there is some interesting analysis to be found in this article as well.

[1] https://www.openapis.org/blog/2023/12/06/openapi-moonwalk-20...

I like that idea but I purposely stay anonymous on HN and I would be DOXing myself if I used this. It'd be great to be able to either use it without a username (ideally) or have the choice to keep your HN username private.

Generally yes but the languages are similar enough that the refactoring could be automated. Of course, that would create a fair amount of QA and testing work but if you have good test coverage you can mitigate that.

(Sorry for the delay, I haven't checked HN is a while and just noticed this)

So some proxies (forward and reverse) will strip this header for different reasons.

The reverse proxies sometimes strip it to improve caching and/or because they were configured to have a allow-list of headers and this (being a less common one) was excluded.

The forward proxies will sometimes strip it for privacy reasons (it can be used in fingerprinting) or for the same reason (they have a list of allowed headers and this isn't one).

In my experience Accept-Language header is pretty unreliable. It tends to just be one of a few values. Between people never updating it, proxies stripping it, people concerned it will make them easier to fingerprint, etc.

Also, form an implementation standpoint, translation is a lot of work to get right and some companies may not do it for all languages so they may support the header but just not support the language choice you have. Yelp being a weird example where they apparently have the Japanese translation on another site.

Combine all that together and it's not usually worth the effort to do it unless you have specific legal requirements or high demand from users.

I'm a little surprised HHVM is still around, last time I checked it was barely (if at all) faster than vanilla PHP and PHP now has a lot of the comparible features like progressive type safety and concurrency (to an extent).

There are even competing PHP compilers/interpreters/runtimes now like there has been for a while with other languages.

I'm guessing there is some benefit to running HHVM on the type of large scale deployments Facebook has or there wouldn't be a need to keep it around.

As someone who has given a handful of talks at conferences.. 100% relatable.

That example you gave could certainly be done in Lex/Flex and I assume other lexers/tokenizers as well, for instance, you would probably use states and have "$x" in the initial state evaluate to a different token type than "$x" in the string state.

But I do get your meaning, I've written a lot of tokenizers by hand as well, sometimes they can be easier to follow the hand written code. Config files for grammars can get convoluted fast.

But again, I was not meaning it as criticism. But your talk title does start with "How to write a programming language and shell in Go" so given the title I think Lexers / Tokenizers are worth noting.

That's no problem in many modern lexers as they usually have a "state" so when you encounter "echo" you can switch to a new state and that state may have different token parsing rules. So "if" in the "echo" state could be a string literal whereas it may be a keyword in the initial state.

Lex/Flex takes care of that mostly for you which is one of the benefits of using a well worn lexer generator and not rolling your own.

This seems like a cool project.

This is meant as additional information not criticism. I skimmed the transcript really fast so if this is in there and I missed it, please correct me, but two things I think are helpful for people creating projects like this to be aware of:

- This video seems to combine the concepts of lexing and parsing. It is usually beneficial to separate these two steps and lex the input into tokens before passing to the parser.

- Go actually has a pure Go implementation of Yacc in the toolset and I've used it in several projects to make parses. Dealing with the Yacc file is often much easier than dealing with code directly since it takes care of writing the actual parser. There is a lot of boiler plate that goes into parsers that when you use Yacc it "just works".

Edit: there are also some tools for writing parsers in Lex/Flex like syntax (re2c comes to mind) but I've found hand writing lexers to be effective in Go if your language doesn't have many different types of tokens.

The "hate" is for apps that only pre-package the GPT with a pre-written prompt and don't do much else. And the reason is, I think, because simply making a prompt template is usually not a significant enough value-add except for the most untechnical users. Most users can solve their problems just chatting with the GPT directly.

To get to the first part of your question: no. Every SaaS I've worked on for instance has included months if not years of creating intellectual property (often from scratch) so that the user's are receiving significant value over what they could do themselves.

Jealousy aside, I think they are poor business models because there is little to no barrier to entry.

> what’s here doesn’t come close to covering what we did in the first year alone

This varies widely by University. The Git repo matches my experience pretty well except I also had Calc II and Discrete Mathematics.

> a course on logic programming, another on functional programming

This was already in the Git repo when I looked. I think the "Programming Languages" from University of Washington Courses cover that. Specifically "Programming Languages, Part C"... though it doesn't mention Common Lisp or Scheme and uses a lot of Ruby, which is an odd choice (IMHO).

I've interviewed a lot of different people from a lot of different Universities and I agree a lot of schools treat that as part of Computer Engineering. My undergrad was also accredited as an engineering program which may have something to do with it. But with that said, I've seen a lot of CS programs that also have at least some of those courses.

Also, some schools blur CS and Electrical Engineering and for those you may take a whole other set of courses neither of us mentioned.

I had a similar course in college... though we had to build the computer on a breadboard and it was nowhere remotely close to being able to run a GUI let alone Tetris.

Some of this reads as: "How to learn Java in just 1.5 years!"

And notably (and related to my Java observation) there are two OOP classes here.

I like the concept but it is some key things a 4 year degree's sometimes (not saying always!) have:

- Compiler Design

- Architecture (though some of the "systems" courses get into this)

- Databases (there is a DB course in there but it says "Essentials" and it is debatable if it actually even covers that)

- AI / Machine Learning

- Networks / Distributed Systems

- Embedded Systems (less common in CS degrees but almost every CS student I know has messed with Arduinos so it's not a stretch to have a basic embedded systems course)

Also, one of the most fun parts of an undergrad can be the electives, it would be nice to see some electives added here. I took 3D Graphics Programming and Bioinformatics, which I enjoyed at lot.

My undergrad had those things and they are the courses that have been most helpful to me in the real world. But I generally agree, it is rare to see them outside of master's degrees but doesn't mean they shouldn't be in there.

I've coded a ton of shell scripts over the years and never actually considered this nor has anyone I know ever intentionally[1] put protections for it in their scripts so I think the original comment may be overestimating when they say "most of us"

With that said, I definitely ill be looking out for this in the future.

[1] I have unintentionally protected against this by using unique names for my temp files.

Saw this article title and immediately thought Boston City Hall and sure enough, that's one of the images they included. I know at least one university in Boston that recently renovated a brutalist building to look more "modern".

The article doesn't mention this directly but I wonder if part of the repulsion (at least in the US) is a subconscious association with The Soviet Union.

While I agree it's not really security through obscurity because when combined with other strategies (like mitigating timing attacks and rate limiting) it does expose less information to the attacker.

However, I stand that it does depend on the application. For example: Facebook does not use generic error messages. I presume because there are other trivial ways to find out if a user has an account so mitigating enumeration through the login form is not actually adding extra security.

It's not quite so clear cut. Close. Even OWASP acknowledges there are trade offs:

> The problem with returning a generic error message for the user is a User Experience (UX) matter. A legitimate user might feel confused with the generic messages, thus making it hard for them to use the application, and might after several retries, leave the application because of its complexity. The decision to return a generic error message can be determined based on the criticality of the application and its data. [1]

Though it's a pretty low bar. Given the common uses of Wordpress, there is certainly a very strong argument that it warrants the extra security.

I'm not defending its UX, I think it should have more generic errors. Just pointing out that this one particular example is not in and of itself the best banner to hold up when it comes to bad security as it is not a clear cut answer. A person could be very considerate of security and still come to the conclusion that the better UX is worth the risk.

[1] https://cheatsheetseries.owasp.org/cheatsheets/Authenticatio...

> NAT GW is $0.045/h even if doing nothing, plus $0.045/GB, plus egress. IP is $0.005 without any extra costs other than the standard

That's only 10 servers. I sometimes forget they charge per GB too. That particular charge rarely affects me but if your private services need a lot of data that can certainly add up.

To expand on that, additionally, if you are running your own NAT you need to have one instance per AZ or you end up with cross-subnet transfer costs. So that's at least one cost that you save with NAT gateway (though moot if you run all your services in the public subnets)

It's not the complexity (IMO), it's the cost. A hobbyist can easily set up NAT gateway but very often the NAT gateway is the most expensive part of the entire cloud bill. So the hobbyist is left with paying it or exposing their server to the public internet. It is very expensive for what should be something that is a built in part of VPCs.

Heck, even if you're not a hobbyist, I've worked with companies that have dev environments that mirror production (except smaller instance sizes) and now all the sudden you have a ton of NAT gateways eating money for providing a basic networking service.

You could do A but in addition to the security issues now you have to pay for public IPv4s on AWS too so if you have a significant number of services that are private but need internet access it is still cheaper than NAT gateway but just barely.

I've done B before for dev environments and it works well. For production there is a large list to make it high availability.

Which brings up one of the travesties of NAT Gateway is if you have a dev (or more) and staging and you want it to match prod you're all the sudden stuck with a paying for multiple NAT gateways.

While I suspect this may be old news to a lot of the HN crowd, this article interesting information that a lot of people may not know.

I ran a website years ago that was targeted towards college students and would pretty consistently see many (hundreds) different UAs under the same IPv4 address due to NAT. Let alone proxies, VPNs, etc.

Yet every once and a while someone will suggest the idea of rate limiting based on IP so it's definitely not universal knowledge even among developers how common it is for multiple users to share the same IPv4.

> But it’s generally both inexpensive and fast.

I guess inexpensive is relative. I've been on cloud for a while so I'm not sure what the going rates are for "remote hands" and most of my experience is with on-premise vs co-lo.

> Two of everything may still be cheaper than expensive cloud services.

That is true. Everything has tradeoffs. Though in the OPs case I think the math is relatively clear. With Open AIs pricing he calculated the break even at 5 years just for the hardware and electricity. Assuming that calculation is right, two of everything would up that to 7+ years, at which point... a lot can happen in 7 years.

I've managed both data centers and cloud and IMHO, no, it is not fluff. To take it in order:

> doesn't have security issues

It sure does, but the matrix of responsibility is very different when it is a hosted service. Note: I am making these comments about Bedrock, which is serverless not in relation to EC2.

> It crashes

Absolutely, but the recovery profile is not even close to the same. Unless you have a full time person with physical access to your server who can go press buttons.

> data loss

I'm going to shift this one a tiny bit. What about hardware loss? You need backups regardless. On the cloud when a HDD dies you provision a new one. On premise you need to have the replacement there and ready to swap out (unless you want to wait for shipping). Same with all the other components. So you basically need to buy two of everything. If you have a fleet of servers that's not too bad since presumably they aren't going to all fail on the same component at the same time. But for a single server it is literally double the cost.

> doesn't involve lots of administration

Again, this is relation to Bedrock with is a managed serverless environment. So there is litterally no administration aside from provisioning and securing access to the resource. You'd have a point if this was running on EC2 or EKS but that's not what my post was about.

> Thinking that we don't know any better is both disingenuous and a bit insulting.

I'm not saying cloud is perfect in any way, like all things it requires tradeoff, but quite frankly I find you dismissing my 25 years of experience, 1/3 of that has been working in real data centers (including a top-50 internet company at the time) as "fluff" as "disingenuous and a bit insulting".

Llama-3 is one of the models provided by AWS Bedrock which offers pay as you go pricing. I'm curious how it would break down on that.

LLAMA 8B on Bedrock is $0.40 per 1M input tokens and $0.60 per 1M output tokens which is a lot cheaper than OpenAI models.

Edit: to add to that, as technical people we tend to discount the value of our own time. Bedrock and the OpenAI are both very easy to integrate with and get started. How long did this server take to build? How much time does it take to maintain and make sure all the security patches are applied each month? How often does it crash and how much time will be needed to recover it? Do you keep spare parts on hand / how much is the cost of downtime if you have to wait to get a replacement part in the mail? That's got to be part of the break-even equation.

A lot of people is assuming the change is AI related but it sounds more like they are going to start (or maybe clarifying that they already do) actively monitoring creations for illegal activity and the like. I'm reserving judgement here / just making an observation.

The "worldwide royalty free distribution thing" is more or less the standard industry terms when a cloud service is allowed to redistribute work via something like a share button. But I wonder if the terms can be more explicit in general (for example: only grant the license if the user uses the "share" functionality on that particular file)