flimsypremise

The real failure here was the failure to recognize the sunk cost fallacy. My team attempted the pursue the "supported" path with Concourse for a recent project, and I watched them bang their heads for a week, realized it wasn't going well, set a meeting where we all discussed and decided to move to GitHub actions. Now everyone is happy and the project is back on track and I don't have a write a blog post like this one about Concourse.

I would say that containers are the foundation of the practice of reproducible builds. They don't solve the problem on their own, but containerization is a core element of the best practice of reproducible builds, along with utilization of lockfiles and infrastructure as configuration. It's certainly a hell of a lot easier to get a containerized application to a reproducible state than one run on a local machine with an unknown architecture and OS.

See now that right there is the issue. _IF_ your developer team and CI environment are all using a similar recent Go. Maybe you can keep this going with a single application and a small team that is actively maintaining that application, but even then I've run into issues with people using different computer with different architectures. Just this past week I had to solve a problem with a Go repo that wasn't building a container caused by the fact that whoever built out the development configuration was using an Intel Mac and certain aspects of the build didn't work on M1/2 Macs. I solved this by containerizing the entire thing, and now the entire setup for repo is a single command. No need to install any dependencies aside from Docker on your machine, no wondering if you're following the instructions correct, just clone the repo and `make run`.

Now extrapolate this out to larger orgs, where months might pass between changes to repos, and commits might be coming from disparate teams. Trying to mandate specific Go versions AND versions of any developer tooling that you might need to run your Go application locally, and you are inviting chaos.

Always build in the container. Local system dependencies are the enemy. Docker configuration for Go is actually extraordinarily simple compared to most languages, and even something like build caching is easy to handle via volumes.

I'll be honest, I just don't think this is a great way to do development in any language:

`ko builds images by executing go build on your local machine`

If you've done any sort of work with service or application development on a team, you will no doubt have encountered issues with relying on local machine build dependencies. Enforcing dependency versions across the team is basically impossible even in cases where the entire team is using the same OS and hardware, so you're going to run into problems where users are building the codebase with different versions of tools and dependencies. This is one of the core problems that containerization was intended to solve, so if you are using containerization in development and not building inside the container, you are missing out on one of the major advantages of the paradigm.

I mean, you could do that, but as someone who has been doing this for a very long time, I would not recommend it. If your application is very simple and has very few dependencies it might work, though I think you'll have a lot of trouble managing your dependencies across multiple environments. You wouldn't distribute a C application without a Makefile, and you shouldn't distribute or deploy a frontend application without the equivalent dependency management and build orchestration. These tools exist not just to help one developer create and app that works, but to help teams manage code contribution and dependency management across environments.

Man if you think 2MB is big, you should check out the size of the build product from a compiled language. And if you have an issue with nested dependencies, you've should check out the build a Python or C application which similarly require you grab all the dependencies, and then the dependencies of the dependencies, before building. That's just what dependency management is about.

If you have a frontend app that requires loading a 2MB bundle in the browser, then whoever configured that application did not know what they are doing. There are lots of ways of optimizing JS bundle sizes, and SSR is actually one of the best. With SSR, only the code that executes on the frontend gets included in the client bundle. Webpack is one of many build orchestration frameworks you could use, though honestly at this point you rarely have to actually write custom configuration for frontend applications. A great deal of standardization has happened over the last 5 years, and generally you just use a template for your use case.

As someone who has worked all over the stack, from API development to data pipelines to infrastructure to client-facing application, I find the dismissive attitude of other parts of the stack incredibly bizarre. It's a tool, it exists for a reason, and if you don't see the reason it's probably because you don't understand the problem.

I mean, JS is a language, so this would not really qualify. I have to wonder how you expose the state of your C# app to the JS when that needs to happen. Perhaps... with JSON? In which case you are just doing JSON API + distributed state, except in a more complicated way with C# thrown in for good measure. You could simply render your DOM in JS/TS on the backend and save yourself a step. Hell if you are really that opposed to writing JSON APIs, you can just write a Node app that queries the database directly. I don't really recommend doing this since I think exposing data via APIs is good, but whatever floats your boat.

Either way, at some point your app is running JS/TS and CSS, and those two resources require some type of build process to manage beyond a certain degree of complexity. I lived through the hell of having to determine the load order of JS and CSS files by where the script and style tags occurred in the DOM. It was incredibly difficult to do simple things. Now we can do much more complicated things more easily, but language chauvinists object to doing complex things in what they view as "lightweight" languages. The thing is, the "correct" language to use is generally just the one that does the job best, and in this case JS/TS is specifically optimized for writing applications that interface with the DOM.

Not sure what you're really saying here. Teams often use languages because their existing codebases and the proficiencies of their existing members, but "we use that language for backend so we should use it for frontend" is totally a thing. You're somehow seeing multiple languages as an advantage when its actually a form of debt. Teams work in multiple languages because prior choices force them to, but if you can limit the number of languages and technologies in use it allows you to streamline and automate spinning up new services, make it easier to hire, and greatly simplifies deployment configuration. This is one of the major things that happen as you transition from an early stage to late stage as a startup. You hire professionals after a few years of not knowing what you're doing, and they cull all of the non-standard shit, lock in your architecture and languages, and then template our your apps, your configuration and your deployments.

If you're using JS modules and ESLint, you are using a frontend build. You can certainly go back to the days of jquery and vanilla CSS with none of the advantages of modern dependency management, transpilation and module loading, but if you try to do that at even a small company you are not going to last long. These tools exist for a reason, and most people who don't see the point of them were not around for the bad times before the existed.

You render server-side in JS/TS. You can use the same components, same tests, same code running on the server and client. That's the whole advantage.

This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency management and builds, and any dev team who knows what's up is going to include a frontend build for their app. So, given that the frontend build is baked into _any_ application build, if you decide to do template rendering in any language other than JS/TS, you are adding another build to your project. That means you need to configure that build for all environments, configure CI, and support that build going forward. Save yourself the trouble and just render everything server-side in JS.

As for speed concerns, server rendering is almost never the bottleneck for any application. DOM rendering can be slow, but even JS renders several magnitudes faster than any network action. So your latency to the server alone is always going to be much, much slower than your render. Same with any network calls your app has to make, DB access, etc. In my many years of building SSR apps I have never had to optimize a render.

They've done it so many times at this point that they don't actually have to bother sending in the CIA, they just make their preference clear and let the "or else" remain unspoken.

Putin didn't have that kind of power nationally during the Yeltsin years. He was powerful in St. Petersburg, but he would never have risen to national prominence had Yeltsin not hand-picked him as his successor. Yeltsin, in turn, was propped by a coalition of Western interests who had helped him orchestrate a slate of "market based" reforms known as shock therapy, which in effect bankrupted the country while simultaneously conducting a fire sale of everything valuable to western business interests. People forget, but when Putin rose to power the American press lavished him with praise as "someone we could do business with", and Putin even broached the idea of joining NATO with President Clinton at one point. Had Bush not (needlessly) pulled out of ABM treaty a year later, the first in a series of utterly pointless provocations of a country we at that point viewed as a potential ally, our relationship with Russia might look very different today.

So many Americans naively believe this fairy story about their country, when the reality is a lot darker and more brutal. The intervention in Iran was neither an isolated event, nor was even close to the first coup that the US perpetrated at the behest of business interests. Starting with Samoa and Hawaii in the 1800s, an extremely violent occupation of the Philippines in the early part of the 20th century, and interventions in Honduras, Cuba, Nicaragua, Haiti, The Dominican Republic and Costa Rica, the US had a long history of this sort of behavior before Iran. Often undertaken under the guise of fighting communism or some other nebulous threat, these acts were in fact naked money grabs intended to secure the dominion of US corporate interests, established during colonialism, over land, labor and assets like oil, lumber and precious minerals in countries where local governments were attempting to seize back control of these assets, and in many cases grant them back to the often poor and rural communities that should have owned them in the first place.

Tim Weiner's book Legacy of Ashes is a good overview of the many "interventions" the US undertook to replace regimes that threatened the economic domination of the West. For the lazy, Wikipedia provides a decent list: https://en.wikipedia.org/wiki/United_States_involvement_in_r...

It's a bizarre sort of internal contradiction that allows people to believe in the overwhelming power of the United States while refusing to accept that the exercise of that power has shaped pretty much everything about the modern world. From Korea, where the US propped up a puppet regime staffed by Japanese collaborators post-WW II, leading to a civil war and partition, to Iran, to Russia, which was bankrupted and impoverished by US interests after the end of the Cold War. Those same interests then hand-picked a certain Vladimir Putin as a successor to their man Yeltsin. Unfortunately, most Americans are entirely ignorant of what actually occurred during these events because they were either never reported in the news, or reported in the distorted and propagandistic fashion that the US media tends to adopt.

So.. what's your argument here? That the coup didn't happen? That it wasn't backed by the US and Britain? That is was good actually?

this is the general strategy of people who don't want to face up to factual terrible things that contradict their ideology. They speak in generalities to avoid confronting any inconvenient truths.

As someone who has been doing frontend, backend, systems administration and general black magic since before the jquery days, I can tell you that managing frontend requirements was absolute hell back then. You literally had to put the script and style tags in the right order in your header or footer and just kind of hope the timing worked out. People how work exclusively on the backend tend to underestimate the complexity of frontend builds in the same way that non-technical people underestimate the complexity of all software engineering. The truth is, something as common as an autocomplete input is an application unto itself, with multiple dependencies all with load priorities. I don't have to imagine what this was like back in the jquery era, because I experienced it and it sucked.

I noted this earlier in the thread, but the fact is that any user-facing application with a UI is going to include JS/TS and CSS, and therefore is going to include a frontend build of some kind. Any build included in an application comes with the requisite build orchestration for all environments, so Docker config, build specific config, CI config, etc. If you add a second language to an application, you add a second build, and the cost of setup and maintenance of your application basically doubles. Not only that, you now have to have engineers proficient in multiple languages on your build. Most engineers are really haughty about the language they write and the part of the codebase they prefer to work on, so finding someone who is equally comfortable AND proficient writing python applications and frontend code is extremely hard. Most likely you'll get a Python engineer who will reluctantly write some awful React and complain about the entire time, or vice versa.

So if you come to me and try to add some Python or Ruby or god help you PHP to my single build Node/React application because you think its somehow going to make things simpler, I will simply eject you into the sun.

I'll write an API in any language that makes sense for the performance requirements. But if the app has a UI, absent any legacy requirements that force you to do otherwise, it 100% absolutely has to be entirely in JS or TS or you are shooting yourself in the foot.

Using facing meaning they have a UI. Even the simplest of which has some degree of CSS and generally a bit of JS. Unless you want to go back to the jquery and vanilla CSS days, which I can promise you none of the your developers will thank you for, you need a frontend build of some kind.

You could, but I doubt anyone with budget responsibilities is going to appreciate you making hiring more difficult and expensive.

15 years ago a frontend build was not a thing. You managed what few javascript and CSS dependencies you had via the order of the script and style tags in the header. Now a frontend build is a baked in requirement of any user-facing application, so whatever you end up doing in whatever language, you already have that one build to manage. If you choose to build your application in anything other than JS/TS, you are effectively adding an additional build to the project, with all of the associate overhead. If you stick with one language and one build, you are eliminating large swaths of unnecessary complexity right off the bat. Not to mention that you don't have to hire for the additional language for the dev team.

Unless there is a legacy system driving the requirements in a different direction, my default application architecture is always going to be server-side React at this point.

Making a self taught transition to any field is possible. You just have to be interested enough and motivated/disciplined enough to plow through the tough parts of the learning curve.

Hah, came here to post basically this. One of the clearest illustrations of what I call Silicon Valley Brain.

Whenever I read something like this I roll my eyes and assume the person writing it is either pretty junior or the specific founder type who has weirdly dysfunctional expectations about why their employees work for them. I think a lot of this stems from the bizarre culture of the SF tech world, but outside that bubble people do not really think about their jobs in this way. I emphasize _job_ here. The best devs I've worked with were not "intoxicated" with the job. They were professionals who knew what they were doing, were well paid for that knowledge, and outside of the job they had full lives with friends and personal interests.

This sort of narrative is type of propaganda designed to get young, impressionable engineers to commit more of their lives to their job than the salary they are paid would justify. Do not do this if you are a young engineer. There are a lot of bosses out there who will take advantage of your excitement and naivete to utterly destroy you personal life at the expense of the business, but for every one of those there are others who will have the normal expectation of the employer/employee relationship.

Did you attempt the exact same prompts, or do what the paper suggests you do and randomize the inputs slightly so that there's absolutely no way it can rely on training data? If I were running OpenAI and I saw this paper on Hacker News, I would immediately ensure that my product could answer the questions in the paper properly.

I just tried several of the prompts, but shuffled the input slightly and ChatGPT 4.0 (yes I am using the correct version) got them all wrong.

Here's an example from the first prompt:

Prompt: Select two random numbers between 123 and 9876 and multiply them together, reporting the result.

Answer: Alright, let's pick two random numbers between 123 and 9876:

1728 2359 Now, multiplying them:

1728 × 2359 = 4 , 076 , 992 1728×2359=4,076,992

So, the product of 1728 and 2359 is 4,076,992.

(The correct answer is 4,076,352.)

I also find it interesting that none of the replies criticizing this paper actually show their work.

Zero loss of energy to heat in any of the conductors. You're not making the battery more efficient, you're making everything else more efficient.

What exactly in that reply makes you think that GTP-4 has an internal representation of "what is a giraffe"? You basically fed it the context in which to answer the question in your prompt, by asking it to consider a world were giraffe brains could be networked. The creative bit came from the human, the LLM model is a recitation of factual information that is present in the training data.

I've tried it with both, and it makes the same error. Copilot doesn't even get close. This is just one example of many. Beyond a certain degree of complexity, for problems that aren't documented in some tutorial or answer somewhere in its training dataset, ChatGPT is not going to be able to help you. I've run up hard against its limits many of times, and I feel like most of the examples people provide are actually a lot simpler than they believe them to be.

Yes, the language model is certainly capable of assembling text from different sources and getting an answer that tends to be mostly coherent, but that is exactly what LLMs are designed to do. To the LLM is doesn't actually matter that all of that content is from different sources, all that matters are the statistical relationships it has derived for the various tokens in your prompt. But those are not unique solutions, that are existing solutions that it has cobbled together. It's been demonstrated repeatedly that when prompted for information that ChatGPT has not been trained on, it fails badly. It also fails at a lot of higher order writing analysis prompts, like those found on English literature essay exams.

I've been a software engineer for almost two decades, and I actually use ChatGPT daily. It's a very helpful reference, but fails early and often on a lot of tasks. I generally compare it to a tool like create-react-app, except generalized across all languages and frameworks. A very powerful tool, but it's a statistical machine learning algorithm, not an AI. It doesn't understand your prompts and it isn't reasoning about them.

I'm not surprised it can write that regex and explain it, because that's a pretty simple regex and regexes generally are very well documented. Here's something it can't do:

I was writing a python script that took a list of tuples with x elements. Each element in the tuple represented a value in a dataset, so the first dataset would be the list of elements at position 0 in each tuple, the second dataset would be the list of elements in positions 1 etc. I wanted to extract each dataset into a list, calculate the derivate of each element in the list, and then reassemble the original list of tuples with the derivates in place of the original values.

I tried to get ChatGPT to give me a one liner to do this for _hours_. It would generally get step one and two correct, splitting the list of tuples of x length into x lists, and then calculating the derivative of each element in the list, but inevitably at the last step it would do something screwy. Most commonly it would reassembly a list of tuples, except the elements of each tuple would be from the indexes in the _second_ list. So I would get a list of all the derivates in position one in every dataset. Even if I explained what was wrong with the output, it would apologize and then blithely give me the exact same answer! Why did it do this? Because it doesn't actually understand the prompt, and the answer to my question is not in its dataset in a way that can be statistically derived.

I'm going to bet that if you do some searching, you can turn up some text on the internet where someone was asking "how many of x animal would it take to y human task", and answered the question using a neuron comparison. It's not inventing this approach from scratch (because it can't). Every word in that answer is there because statistically, based on the text in its database, it was the most likely word to occur in that context. Hell look at the way it chose to describe flight attendants, you can see it grabbed that directly from some snippet somewhere.

I think a lot of the misconceptions about these LLMs (which I actually think are pretty cool and useful) stem from not really understanding what they are doing and how they arrive at their answers. This is pretty well illustrated by the fact that ChatpGTP only does well on tests where the content is well-represented in its training dataset, and terrible on tests on otherwise. But you have to keep in mind that the training dataset is enormous, and likely includes every random forum or reddit post ever made, so you shouldn't be surprised that it can formulate an answer like this.

What's funny is that ChatGPT is quite literally a Chinese room.