jpulec

It's not. The API is different, since GPT-4 is a chat based model, and davinci isn't. It's not a huge difference, but these little sort of things add up.

I've been using the JS version of langchain for a few months now, and despite there being a lot of valid criticism, (especially around the abstractions it provides) I'm still glad to be using it.

We get the benefits of a well used library, which means making certain changes is easy. For example, swapping our vector database was a one line change, as was swapping our cache provider. When OpenAI released GPT-4, we were able to change one parameter, and everything still just worked.

Sure, it's moving fast, and could use a lot better documentation. At this point, I've probably read the entire source code several times over. But when we start testing performance of different models, or decide that we need to add persistent replayability to chains of LLM calls, it should be pretty easy. These things matter to production applications.

Arguing that Tailwind is a leaky abstraction for CSS is like arguing that ORMs are leaky abstractions for SQL; hiding the underlying implementation isn't the point of these tools.

The biggest benefit is that you get a fairly well thought out API to work with. In the case of Tailwind, this a pretty flexible and good set of defaults that works for 95% of use cases. You can focus more on building classes for cases specific to your site, and not spend time rebuilding undifferentiated layout utilities.

You don't have to host it yourself ;)

Beyond that, there are a couple of things that I don't believe bors has.

A big one that I built for myself was the idea of supporting "working hours", i.e. only merge code during this timeframe.

For example, one company I worked for had some pretty flaky tests. Unfortunately, what would happen is we would have several PRs get reviewed and then use a tool like bors to enqueue them. Inevitably, some queued PR would have a failed check for this flaky test.

Fast forward to the weekend and a completely different developer would merge a hotfix into master. Unfortunately, a side effect would be that a tool like bors would try to merge the head commit into the PR with the flaky test, and now it passes! So it gets deployed at a random unexpected time, which isn't what we wanted.

I launched mergecaravan.com to deal with a problem I've encountered at a few jobs in the past. Mostly, I built it initially to scratch my own itch, and to go back to doing more django dev.

Basically, you can add a label to a PR in github and it will then queue it up to be merged once all the required checks pass, and it keeps queued PRs "up-to-date".

It's made a little money, but not much.

Github recently rolled out a feature at Github Universe that has overlap, so I'm guessing it won't get much more traction.

A few lessons I learned: - Especially when building on a platform, make sure you have the right niche. In this case, it probably has a wide enough audience that Github decided it was worth it to build as part of the platform. - Like any engineer, I spent too long building and let scope creep delay me from launching.

All in all, it's pretty cheap (read: basically free) to run, but I probably committed somewhere over 120 hours on it.

As a very happy Metabase user, glad to see this. Hope the team uses the money to make the project better while still keeping its open source roots.

I've used StitchData at a startup with AWS Redshift. Pair it with something like dbt for transforming your data, and you have a great match. A little pricey, but totally worth it, IMO.

Chewse | Fullstack Developer | San Francisco | ONSITE | https://www.chewse.com | $115-162k

Chewse is weird little family who works with offices to run their meal programs.

We're looking for individuals who want to work as part of a small team, and have a lot of responsibility for what they produce. Humble confidence strictly required. Previous experience with Python and JS nice, but not required.

Process: Initial phone screen, technical phone screen and take home question, video chat, full day onsite

Come bring your heart to work!

Came here looking for a comment like this. If you're not discussing HATEOAS at all, you will be losing out on many of the benefits that REST provides.

Having a clear salary expectation up front just saves both parties time and effort. One of the big reasons salary ranges aren't always public, is because it benefits the company, by maintaining information asymmetry. By but doing that, you're at least in a small way, telling me that you don't want to play that game and are more likely to be transparent with me about other parts of the process.

I was the first engineer hire at a small startup, and have helped our CTO/Co-founder grow the company over the past 3 years.

All I can say, is that almost everything that was said here was the exact experience we had. Even down to the choice of Angular 1.X and rewriting all of the IIFEs in our codebase to use ES6 imports with babel.

I also need to acknowledge that PM is something that you do fine with 2 people, but your processes will fall apart, probably as soon as you even hit 4 or 5 people.

I think lambda syntax can be a bit cumbersome, but that aside what I really miss is a clean syntax for chaining functional operations. So often I find myself thinking about data in terms of 'pipelines'. i.e. in JS:

  _.chain(values)
   .map(() => {})
   .flatten()
   .compact()
   .uniq()
   .value()

vs Python where doing the same thing becomes either a nested mess of function calls or comprehensions or a for loop.

While I resonate with the sentiment, I just wish Python would add better syntax for functional programming. Having written a lot of JavaScript lately, I wish Python's built-in functional tools supported something cleaner, kinda like Underscore/Lodash.

Being from Wisconsin, I always get called out for how I pronounce "bag" and "bagel".

I had the same thing happen to me.

I feel like I relearn this lesson at least once a month.

Couldn't help but think the same thing as I read this.

Actually, this exact issue was also an issue in Debian. The bug reports can be found further down in an answer to the same stackoverflow question. It may now be fixed, I'm not sure.

EDIT: Title changed from "Why Python 3 Isn't Being Used More" to "Problems With the Python 3 Ecosystem"

Ubuntu is one the most deployed server distributions of linux, and one of the most battle tested. While this post isn't meant to criticize python 3 (I think the language is perfectly fine as is), it's meant to criticize the ecosystem, where one of the most deployed distributions doesn't work.

Perhaps the title should be altered. My main argument is that the ecosystem around python3 is what's holding it back. I think the language itself is perfectly ready, and even most major packages have been ported over.

Check out https://python3wos.appspot.com/ . The majority of major packages have been ported over. Most of the bigger stuff is often run independently and not actually imported by other code (sentry, supervisor, ansible... to name a few).

This is awesome

More modular? I think how modular it is, is one of Django's greatest strengths. Don't like django's templating? You can be up and running with jinja2 in less than 20 lines. Don't like Django's user model? Substitute your own, or if you just need a different auth backend, write your own. Have a desire to use a less common DB? Write a db backend. As far as trashing the ORM for SQLAlchemy, there are a number of django packages that aim to do just that.

There is a small number of ways I could imagine Django being MORE modular.

I worked at DoIT before graduating and moving out to the Bay Area. And your characterization regarding its bureaucracy and efficiency are pretty spot on.

I'm of the belief that you should reveal as little information as possible regarding your web stack. This alone indicates that they're running Django, although that could probably could have been guessed pretty easily considering it is Python.org . Also, from a security perspective, I would prefer to have the admin site only accessible from an internal network, perhaps on a subdomain, and require people to use a VPN to make any sort of admin changes.

http://www.python.org/admin/ shows Django admin.....sigh...

> So I think they picked up a little bit of the brogrammer culture and kind of said: “Yeah it’s OK to yell at each other because we’ll obviously just meet over beer and pound each other on the back and it will be all fine.”

> Sometimes, that just doesn’t work for people who aren’t men.

I also found this to be confusing....

Unfortunately, in my experience, Chrome's WebGL performance is several times better than Firefox's. Upon several benchmarks, there is just no comparison.