I’ve worked with Azure for a few years now, AWS and classic data centres for 15 years before that.
It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
I see a problem like granting */read in an innocuously named role and am left wondering if it was pragmatism, because figuring out least privilege was tough, or a junior who didn’t know better and was just trying to make progress.
I’m on a phone and can’t search git effectively, but I’d swear there was a comment or note on the golang implementation of msal saying that it used non-idiomatic go with no real support for many of the auth flows in v1 because it was written by an enthusiastic junior dev and released with little review. The modern version looks better, but I felt like I got a window into Azure back when I read that.
Building large services is hard, my hat is off that Microsoft is making it work, but sometimes we get to see that it’s just teams of developers doing it for them and those teams look a lot like the teams we work with every day. There’s no secret sauce, except that MS has the resources to iterate until the thing mostly works most of the time.
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination.
I've come to the same conclusion after dealing (and reporting) jankyness in both the Azure (ARM) API and especially the CLI. [0] is a nice issue I look at every once in a while. I think an installed az cli is now 700 MB+ of Python code and different bundled python versions...
Why do all these use Python? AWS, GCP, Azure, all three CLIs use Python; they're slow, bloated, heavy to install... what advantage does Python really offer here? You can't in any sensible way rely on it being installed (in your linked issue we see that they actually bundle it) so it's not even an 'easy' runtime.
Python takes up less than 16 MB on disk (python3.11-minimal + libpython3.11-stdlib on Debian) so whatever Microsoft did to make their Azure CLI package take up almost 700 MB, I don't think the language is the problem.
It might well be part of the problem. Certainly any language can be inefficient, especially in terms of size, if you don't pay attention (have certainly found this with Go recently). But as I said it's also slow (interpreting code, or dealing with cached versions of it) and it's not obvious to me why all three major cloud CLIs have chosen it over alternatives.
I don't understand the Python hate. What would they use instead?
Python is installed on most systems and easy to install when it's not. Only Azure is dumb enough to bundle it, and that was a complaint in the bug - there's no good reason to do so in this day and age.
The performance bottle neck in all three is usually the network communication - have you seen cases where the Python CLI app itself was using 100% of a CPU and slowing things down? I personally haven't.
Looking at the crazy way Azure packaged their CLI, it's hard to believe they weren't making it bloated on purpose.
And which Python are you talking about? I mean, Python3 is forward compatible but you SoL if you have the bad luck of having an older interpreter installed and you want to run a script which uses a new construct.
I don't understand why Windows people are completely okay having to install all kinds of crazy service packs and Visual C++ runtimes anytime they install anything, but then having to install Python seperately makes it a no-go.
Also, AWS is 10 years older than Rust, and C# only runs on Windows (at least it certainly only did when AWS was created, and is laughably more difficult to get running on Linux or OSX than Python).
> It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
You can say that for the APIs themselves. It's like every API call has 80% of the info I want, but the other 20% that logically belongs with that 80% has to come from multiple other API calls.
The one that annoys me on a daily basis is fetching the logs for a pipeline run. The endpoint is `_apis/build/builds/<id>/logs` and it returns a list of pipeline log objects without the task name that generated them. You get an object with these fields: `{"lineCount", "createdOn", "lastChangedOn", "id", "type", "url"}` but no mention of the pipeline stage that generated it.. whether it's the build step, test run, publishing stage, etc. And those ids change (for example if you re-run a failed job, the unit tests may have ID 4 from the first run, and ID 17 for the second try), so you can't just rely on that.
And the pipeline log viewer on the website is garbage. When you click the link to view the logs it doesn't show you the logs it's collected already but starts showing new logs from that point forward and even for that, sometimes it truncates output and will skip lines. Somehow they managed to make trawling through logs even worse than it would normally be.
The new Notepad would hang for minutes if you used it to open a large text file. It also stuttered when scrolling. It’s incredible to see something so low quality make it into a core operating system app release.
> a junior who didn’t know better and was just trying to make progress
While totally plausible, that's kinda besides the point IMO. This shows regardless of how it happened, they don't have sufficient test coverage of these roles. Meaning built-in roles cannot be trusted.
AWS documentation is similarly bad: I used to joke that it was all written down to remind the service team of something rather than as something that is useful for users to read in advance and understand the service.
It’s only a feeling, but I’d swear I’ve seen variations on this post across a half a dozen software-adjacent subreddits every day for the last month. The common denominator has always been “Paying $200 for Claude Max is a steal” with absolutely no evidence of what the author did with it.
Yeah, I was about to say, it sounds a lot like this guy is just riding an intense high from getting Claude to build some side-project he's been putting off, which I feel is like 90% of all cases where someone writes a post like this.
But then I never really hear any update on whether the high is still there or if it's tapered off and now they're hitting reality.
Fwiw, I use Claude Pro in my own side project. When it’s great, I think it’s a miracle. But when it hits a problem it’s a moron.
Recently I was fascinated to see it (a) integrate swagger into a golang project in two minutes with full docs added for my api endpoints, and then (b) spend 90 minutes unable to figure out that it couldn’t align a circle to the edge of a canvas because it was moving the circle in increments of 20px and the canvas was 150px wide.
Where it’s good it’s a very good tool, where it’s bad it’s very bad indeed.
I think it's legitimately possible to get something done in a week that used to take 3 months, without realizing that you haven't actually done that.
You might have all the features that would have taken 3 months, but you personally have zero understanding of the code produced. And that code is horrible. The LLM won't be able to take it further, and you won't either.
I think we're seeing people on a high before they've come to understand what they have.
Where's the 10x, 20x, or whatever increases in profit from all the AI "productivity"? Typing is not the challenging aspect of writing code. Writing boilerplate faster isn't the super power that a lot of non-technical people seem to think it is.
Libraries and frameworks remove some boilerplate but there's still tons of it. It's rare a library exposes a single doTheThingINeed() function that runs a business. Everyone needs boring but domain specific code.
Are we returning to ideas having importance now since PoC are cheaper and easier? Any dev on HN can create a Facebook competitor, but getting the traffic shift will require some magical thinking.
A PoC has never really been a problem that needed solving. It's going from that to a product that's actually fit for purpose. AWS will happily drain your bank account because you're throwing tons of resources at a poor implementation. Hackers will also happily exploit trivial security vulnerabilities a vibe coder had no ability to identify let alone fix.
This is not the first time the industry has been down this road. They're not in themselves bad tools but their hype engenders a lot of overconfidence in non-technical users.
> with absolutely no evidence of what the author did with it.
I've got colleagues desperate to be seen as on board with all the AI experiments and they just write things like "tool X is MILES better than tool Y". Leadership laps it up
> Especially interesting for software that are 99.9% of the time waiting for inference to come back to you.
In a different domain, I’ve seen a cli tool that requests an oauth token in Python be rewritten to rust and have a huge performance boost. The rust version had requested a token and presented it back to the app in a few milliseconds, but it took Python about five seconds just to load the modules the oauth vendor recommends.
That’s a huge performance boost, never mind how much simpler it is to distribute a compiled binary.
Python's startup cost is terrible. Same with Node. Go is very good, but Rust is excellent.
Even if a GC'ed language like Go is very fast at allocating/deallocating memory, Rust has no need to allocate/deallocate some amount of memory in the first place. The programmer gives the compiler the tools to optimize memory management, and machines are better at optimizing memory than humans. (Some kinds of optimizations anyway.)
TBH I'm still surprised how quickly Go programs start up given how much stuff is there in init() functions even in the standard library (e.g. unicode tables, etc)
I’ve spent some time optimizing Python performance in a web app and CLI, and yeah it absolutely sucks.
Module import cost is enormous, and while you can do lots of cute tricks to defer it from startup time in a long-running app because Python is highly dynamic, for one-time CLI operations that don’t run a daemon or something there’s just nothing you can do.
I really enjoy Python as a language and an ecosystem, and feel it very much has its place…which is absolutely not anywhere that performance matters.
EDIT: and there’s a viable alternative. Python is the ML language.
I know far too much about python packaging while only knowing a little about it.
I agree it’s hell. But I’ve not found many comprehensive packaging solutions that aren’t gnarly in some way.
IMHO the Python Packaging community have done an excellent job of producing tools to make packaging easy for folks, especially if you’re using GitHub actions. Check out: https://github.com/pypa/cibuildwheel
Pypa have an extensive list of GitHub actions for various use cases.
I think most of us end up in the “pure hell” because we read the docs on how to build a package instead of using the tools the experts created to hide the chaos. A bit like building a deb by hand is a lot harder than using the tools which do it for you.
That’s fair. I’m also thinking about the sheer size of Python apps that make use of the GPU. I have to imagine a C++ app performing neural network shenanigans would’t be >1GB before downloading weights.
Figuring out the technique for this involved reading a number of github issues, so I tried to make it as simple as possible to see what the 2 step process is to be able to compile your migrations.
The benefit of this approach with migrations is being able to use golang itself to figure out if a migration should run e.g. you can check an environment variable to see if you're in the dev environment and if you are then you could run a migration to populate your seed data.
Are you just saying here that you open a shell, redirect cat's output to /dev/null, and then use the terminal buffer for notes? I can't quite parse out from your comment what you mean as a workflow; I checked out my copy of Unix Power Tools and didn't see anything clarifying what you mean in either Chapter 43 "Redirecting Input and Output" or flicking through section IV "Basic Editing".
If you have a few minutes and could clarify, I'd appreciate it. I love a good *nix workflow.
Yes that's it: "cat > /dev/null". Or you can even skip running cat and just "> /dev/null". You exit by typing ctrl-d which sends an EOF (and then sends all the output to /dev/null!).
cat > ~/anyrandomfile
also works if you want a persistant connection / want storage to save things
I am not sure if the noteux.com works in the same way.
I am also not sure but is there a way to create persistant terminal connections as each is going to /dev/null but its persistant and you can connect to any of it?
I think there’s potential for a race condition between when you close the Listener and the http server spins up on the no longer reserved port that we’ve seen with lots of tests being run in parallel. You can return the listener, use t.Cleanup to close it and serve your web server on it.
The race condition is definitely there, but if you use t.Cleanup to close the listener then the listener does not stop listening on the port until the end of the test. If you try to bind an http server to the port during a test then your http server will stop and return the error "bind: address already in use".
I'd be interested to know how you're working around that, if you are able to share.
My favourite project of mine is a little web server to support raw html blogs! It can handle serving via ssl, and adds features like an rss feed, a sitemap and a few go templates to make directory listings easy to maintain. The README is pretty authoritative for documentation.
I wrote my site in pure html/css/javascript website, and along the way found that I was unintentionally triggering my site analytics every time I started the site from localhost. A short couple of searches later and I had this rather simple solution.
I decided to do write from scratch for my own site, and found that a real burden was maintaining lists of pages: there was no framework helping me out, and every time I added a new page I had to remember to go update my list of blog posts in the 2 or 3 pages I could access it from.
To solve that and other issues, like adding an rss feed and letting pages specify their own publish date, I did what anyone would do: write a custom web server. It's up at https://github.com/playtechnique/andrew/, if anyone wants to give it a whirl.
A few lines of PHP can solve that. The difference to other solutions is you don't have to compile/build/CI-CD it, just copy the PHP files in a folder, change a few things in the ini and you are ready to go.
For sure! PHP's a great language and tool! You'll still need a web server and modphp or something, and that web server was still probably compiled, but of course with bigger projects you can often get them from your distribution's package manager.
A little project like mine isn't the right answer for everyone; right now its only user is me. How it solves the problem fits my own little brain : )
It’s pretty clear if you check github that Azure’s services and documentation are written by distributed teams with little coordination. We have a saying in-house that the info is all in their docs, but the sentences and paragraphs for even trivial things are split across ten or fifteen articles.
I see a problem like granting */read in an innocuously named role and am left wondering if it was pragmatism, because figuring out least privilege was tough, or a junior who didn’t know better and was just trying to make progress.
I’m on a phone and can’t search git effectively, but I’d swear there was a comment or note on the golang implementation of msal saying that it used non-idiomatic go with no real support for many of the auth flows in v1 because it was written by an enthusiastic junior dev and released with little review. The modern version looks better, but I felt like I got a window into Azure back when I read that.
Building large services is hard, my hat is off that Microsoft is making it work, but sometimes we get to see that it’s just teams of developers doing it for them and those teams look a lot like the teams we work with every day. There’s no secret sauce, except that MS has the resources to iterate until the thing mostly works most of the time.
reply