cjk

I'm surprised this hasn't gotten more upvotes/visibility given how widely used the gorilla stuff is (in particular gorilla/mux).

Thanks to everyone who's contributed to gorilla/* over the years!

Well-deserved, friend!

Damn. That is impressive.

Not myself, but I've seen a bunch of examples folks have posted on Twitter, and to be fair, they were all surprisingly accurate.

As far as I understand it, though, these explanations are based on similar code contained in the training dataset, rather than any kind of ability to reason about what's actually going on, no?

> Everyone in the world will be at least John Carmack-level software capable.

lol

I'm sure that for simple tasks, AI-based pair programming will offer some level of acceleration, but until it can understand the semantics of the code it's generating, and how it fits into the broader _system_, it will not be able to be trusted. I do not look forward to a world where I have to spend my time debugging AI-generated code.

I spent several years creating and maintaining a large, proprietary build system for a Linux-based operating system at a previous gig. Much of userspace was C/C++, and thus used CMake. To further complicate things, most of userspace needed to be cross-compilable for a macOS-based "simulator" environment.

I ended up being fairly proficient with the "modern" CMake language after investing a ton of time into it, but as the size of the company grew, I ended up being a bottleneck. Every other team found themselves subject to CMake's many footguns, and I'd end up having to step in to help.

It was maddening, but I 100% get that other teams just wanted to focus on getting their work done, rather than fighting with a poorly-documented and frustrating build system.

I, for one, would be very happy to see a new CMake scripting language. Ideally, one that is a lot more friendly for beginners and occasional users.

I know some people are comfortable writing blog posts as markdown files and publishing to e.g. GitHub Pages via Jekyll/Hugo/etc., but that's too much friction for me. What little motivation I have to write dissipates quickly when I think about having to go through this process to publish something. And I can't easily write posts from my phone when I'm on the go.

For a brief period of time, I self-hosted Ghost[1], which was great from a writing perspective, but I was really dismayed with how crappy the average request latencies were for visitors.

[1]: https://ghost.org

I think you seriously underestimate the value of job satisfaction and its effects on productivity.

I would also say that dev environments can be “streamlined” and “repeatable” while allowing for personal choice of editor and whatever other ancillary tools the developer is productive with. They’re not mutually exclusive.

Idealism? Hardly. The fact that anyone thinks that Mighty needs to exist signals a problem with the entire web and/or app development ecosystem, in my opinion.

We should be talking about ways to either 1) make it possible to develop performant and resource-sensitive web apps, or 2) make it dramatically easier to make native/native-feeling apps in a way that doesn’t involve so much legacy cruft.

The lack of a solid reason #2 is why Electron-based apps exist and are thriving. Making native apps for each individual platform is hard and resource-intensive.

I have long been a proponent of native apps, but I will be the first to admit that it’s not that simple for small/resource-limited teams. The rise of Electron/etc. is a failing of the pro-native segment of developers. We need a better alternative.

Mighty is such a great example of attacking the symptom(s) of the problem ("Chrome/the web is slow") rather than the root cause (rampant page size/complexity bloat, inefficient use of RAM/CPU, etc.). What a waste of talent and money.

I converted to vim from TextMate, I dunno, something like 10-12 years ago? I've used neovim, specifically, for the last couple years.

I think the thing that originally hooked me were Drew Neil's Vimcasts[1].

I do agree with others here, though, that ~2 weeks is not enough time. You need to force yourself to live with it for longer than that, and any time you encounter a pain point or something that you feel should be less cumbersome, have the patience to Google for solutions.

Personally, I feel that time investment has been worth it, but YMMV.

I'd also probably recommend getting your vim/emacs/whatever setup working really well for one language at a time, rather than trying to make it work for a bunch of different things all at once. Getting e.g. LSP-based autocomplete to work is a very language-specific effort, and is far from plug-and-play.

If it's helpful at all, I publish and version control my vim config on GitHub[2]. I can't guarantee it'll work on anything but my machines, but feel free to send Pull Requests. :-)

[1]: http://vimcasts.org

[2]: https://github.com/codykrieger/dotvim

Meh. I agree with the sentiment, but in practice, I’m not sure we’re there yet. Maybe once Rust has a more robust standard library and less language-level churn we’ll be there.

If you’re writing something safety-critical, sure, use a memory-safe language like Rust/Go/etc. Otherwise, I think C++ is still plenty viable.

IMHO, keep doing what you're doing! Not much better than being beholden to no one but yourself. I don't think it's weird at all to want to keep that going.

Personally, I'm pretty inclined to shy away from VC unless it's unavoidable for the domain the company is in (e.g. hardware companies, which tend to require an unbelievable amount of capital outlay just to survive development + manufacturing).

It's not hard to understand why some people think it's terrible, but I've always adored this movie. I think it was maybe my first experience with anything “cyberpunk.”

Looking forward to watching this black and white version. (Note: available on Amazon for anyone else looking for it.)

I'm impatient and easily frustrated as well. But I've learned to kind of lean into my frustration as a motivator when learning new things.

I try to spend time learning things that interest me personally, and when that happens to overlap with things I deal with at my day job, great. If not, oh well.

I don't really consider how long it might take to learn something if it's interesting to me, and I tend to dive pretty deep, even if I don't get to "expert" level. I figure if I need to become an expert in a thing, that'll come with time.

I dunno. I call bullshit on almost all of these tips. Not all developers are awkward, socially-inept, and incapable of designing their way out of a paper bag. I find that to be a really tired stereotype these days.

I’d say: if you want to be successful, push yourself. All of these things are skills that can be learned.

I'm surprised more folks in this thread haven't mentioned Campfire. I thought Campfire was excellent for its time. I didn't see a real product-focused reason why Slack should have won out, but it undoubtedly had better marketing/sales.

It was pretty obvious based on the ads I was seeing while looking at my mail.

They allegedly stopped doing this in 2017: https://variety.com/2017/digital/news/google-gmail-ads-email...

After seeing Gmail harvest my messages for ads, I started hosting my own email server. It was fun for a time, but got awful tedious, so I switched to Fastmail. They’ve been great. Haven’t looked back.

I was on the receiving end of this. The notifications continued to pour in for another few minutes after I unsubscribed from the thread, totaling 104 by the time the madness stopped.

Something I miss in particular about Heroku's git-push-to-deploy experience is that you'd know whether the build/deploy succeeded by the time the push finished.

Modern “GitOps”-based deployments that rely on webhooks or polling are fine, but it feels so disjointed to me to `git push` and then have to go watch some other system to see if the deploy succeeded.

What I took away from the post is not that Heroku no longer works like that, but that it's a sinking ship, and thus not advisable to use any longer.

I wouldn't say it's _never_ OK to have a multi-page résumé, but as a hiring manager/interviewer I do strongly prefer one-pagers.

I never penalize or reject candidates based on having a multi-page résumé, but I tend to see a strong correlation between candidates with great one-page résumés and great written communication skills. It shows that they've spent the time to consider what's relevant to the hiring manager/recruiter/etc.

IMO, keep the résumé short and sweet, and stick to the highlights, with a heavier emphasis on more recent experience. If you really want to dive into more detail on something, write a cover letter tailored to the position/company you're applying for.

I can’t recommend Fastmail enough. I used to host my own email server after moving off of Google Apps back in the day, and I don’t miss it at all.

Fastmail is reliable and affordable, has great customer service, and supports the sieve language for defining filtering rules. Really tough to beat.

“Focused on speed” and written in Electron.

Sigh.

This is nutty and awesome and I am here for it.

They appear to have moved their status page to Azure.

Current incident report: https://slack-status.azureedge.net/2021-09/06c1e17de93e7dc2

DNS outages are why we put status pages on different domains with different DNS providers. :-)

> "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it takes. But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build."

This.

I often find myself saying “you can be feature-driven, or you can be date-driven, but not both.”