I'm still pre-launch, but I've attended (and presented at) a couple conferences / industry events for my SaaS in Japan. You can get a lot of traction by getting out there and actually talking to people. Networking is important (probably this is the same anywhere?) and talking to other presenters is as important as talking to potential customers, because you can get that relationship going for mutual benefit.
Humans can work with these cases better though because they have access to better memory. Next time you see "iteration_count", you'll know that it actually has a sum, while a new AI session will have to re-discover it from scratch. I think this will only get better as time goes on, though.
You are underestimating how lazy humans can be. Humans are going to skim code, scroll down into the middle of some function and assume iteration count means iteration count. AI on the other hand will have the full definition of the function in its context every time.
Unfortunately, so far coding models seem to perform worse and break in other ways as context grows, so it's still best practice to start a new conversation even when iterating. Luckily, high-end reasoning models are now catching when var names don't match what they actually do (as long as the declaration is provided in context).
Yeah. It used to be the go-to for starting simple projects. We have quite a bit of other options in this space now, though - GH Pages, Cloudflare workers, Vercel, Netlify, etc etc...
They're saying that you have 3 banks of lights, each connected to one phase of the 3 phase input. That way, when only 1 bank goes out, it's easy to see that one phase is out.
Was just rereading - it was the radioactivity and the large natural satellite that was unique in his universe. Tides are interesting because once you have life in the oceans, it's a kind of forcing function to adapt to land conditions
Forcing function + making a stretch of land which is neither dry nor enterily wet. A gradient. If there are no tides the leap life has to make is much bigger.
"Nucleotide formation and polymerization are both more favored thermodynamically when subunit and nucleotide concentrations increase and the water concentration decreases (i.e., at low water activity)" [1].
Tide pools provide a regularly-cycling low-water and high-water environment. (And you get thermocycling, nutrient refreshment, and a path to the oceans, too.)
They're not a forcing function, generally, because we don't know how life formed. But I believe they're close to one in a RNA-first or metabolism-first origin-of-life universe.
Rust is the new C. Go had a shot but went in an applications direction. I predict that very soon, perhaps even inside of three decades, Rust will become the dominant, first-choice systems programming language.
It's important to note that Microsoft's choice of Go for tsgo was because it would be easier to port the existing TypeScript codebase due to the structural similarity of TypeScript and Go. If writing from scratch, they likely would not have chosen Go.
Which is not to say that Go can't do well in tooling. Only that Go was not necessarily their first choice.
That is kinda my point though. None of those are kernels, device drivers, hypervisors, virtual machines, interrupt handlers, bootloaders, dynamic linkers; and writing such things in Go would be an uphill battle against the language's own design, much like the Go runtime itself. Being a GC'd language almost completely fences Go off from even being in the running for these, except for hobby projects trying to prove a point.
Universal applicability may not be necessary to write a Ruby installer, but it certainly is to have any hope of taking C's crown.
MS uses Go for tsc because they are basically doing a line by line rewrite of tsc from typescript to Go.
It's impossible to do this kind of rewrite from a GC language to a non GC one, especially Rust where the object soup of typescript will probably cause the borrow checker to explode.
I think that if MS or someone else decided to write a typescript type checker from scratch there is a high chance Rust will be chosen.
I think Go is going away. It occupies such a weird niche. People have said it's good for app backends, but you should really have exceptions (JS, Py, Java) for that sort of thing. For systems, just use Rust or worst case C++. For CLIs, it doesn't really matter. For things where portability matters like WASM, can't use Go. Bad syntax and type system on top of it.
What if Google spent all that time and money on something from the outside instead of inventing their own language? Like, Microsoft owns npm now.
I always thought of Go as a middle ground between C and Python. From C it gets simple syntax, from Python - "batteries included" part.
Deserializing JSON and XML is a breeze from my experience. And it's available out of the box. But I guess C++ will get there with reflection having been approved in C++26.
So I don't think it will go away (in the coming years at least), since a lot of tools is written in it.
It's not that bad to handle some JSON in C++ or Rust. It can get annoying if you're doing it everywhere, but that's usually that's the kind of use case where JS or Python works anyway. Yes I get that some people prefer Go, but it's not necessary enough to guarantee that it'll stick around.
Actually, I'd say this is where Go has a real advantage. Are any other mainstream languages both garbage-collected (for ease of development) and native-compiled (for ease of distribution)?
Yeah. Only ObjC and Swift, which nobody wants. But JS distribution is arguably easier than building for every platform. Google did that with Gemini CLI.
Also if you're ok being dirty, short-lived processes can just leak. Some of those Go CLIs are probably not even GCing before the program exits.
Maybe - but in this case, Ruby is written in C, it uses C extensions when performance matters, but tooling for the Ruby language itself is all in Ruby. Rust isn't replacing the use of C in the core of Ruby (yet) - it's stepping in to the area where Ruby would have been traditionally used.
Similar thing is in motion with the JS toolchains. Rewriting in Rust is easier than rewriting in C, but why didn't they previously rewrite in something like C++ or Go? I'm guessing because people were simply not interested.
LISTEN/NOTIFY was always a bit of a puzzler for me. Using it means you can't use things like pgbouncer/pgpool and there are so many other ways to do this, polling included. I guess it could be handy for an application where you know it won't scale and you just want a simple, one-dependency database.
> I guess it could be handy for an application where you know it won't scale and you just want a simple, one-dependency database
That's where we use it at my work. We have host/networking deployment pipelines that used to have up to one minute latency on each step because each was ran on a one-minute cron. A short python script/service that handled the LISTENing + adding NOTIFYs when the next step was ready removed the latency and we'll never do enough for the load on the db to matter
You can setup notify to run as a trigger on an events table. The job that listens shouldn't need a pool, it's a long lived connection anyway. Now you can keep using pgbouncer everywhere else.
