1
point
nullspace
Joined 1,697 karma
[ my public key: https://keybase.io/varunkvv; my proof: https://keybase.io/varunkvv/sigs/aCqx43wsQwT5M4kmvrNW3L3Gvg6zc9LH8Hl1nXOajoE ]
- 100% agree. I don’t care about OpenAI or the members of its board at all, one bit.
What I did see was so much incompetence at the one thing I expect a board to be at least okay at. Hiring and firing.
For that alone, I think the board reshuffle was good. Regardless of who you support in all of this.
- For such applications, isn’t the parallelism count usually static and limited? I think there will be good benefits for distributed system frameworks for python. Id agree.
A couple of years ago, I implemented in process parallelism for a system I was maintaining at $JOB. I was happy the system was in Go and not Python. But it was an exception to the rule in my experience.
- What a great article from LWN. It was well-worth reading. As someone who was excited about the NoGIL from Sam Gross when it was first posted here, I think I'm beginning to change my mind after reading this article and reflecting on my own personal experiences.
My experience is with writing backend systems in several different languages (including Python) at various volume/latency/throughput levels. I've basically worked on only two types of systems -
1. one that exposes some sort of an endpoint to the network - it accepts requests of some kind, does computation and other network requests and sends response of some kind (including long polling, ws etc).
2. reads a message from a "queue" (could be database, could be based on polling another api etc) and does computation/network calls and basically sends it to other queues.
Nothing else. Huge variance in specific requirements, but that's it. For the first type of system, latency matters more. For the second system, throughput matters more.
For the first type of system, I want to be able to spin up threads in response to requests, without worrying that an endpoint is too computationally heavy and might block others. I want to be able to share connections to databases in a shared pool. NoGIL would be useful here.
For the second type of system, I can't remember the last time where I wrote one where I had in-process parallelism/concurrency with shared resources (even in langs where there's no GIL). It would just get too confusing and hard to reason about. Any optimizations were mostly based on intelligent batching. For parallelism, you'd just have multiple _completely_ independent processes, probably across multiple machines.
I would absolutely be disappointed if NoGIL meant compromising on the quality of of the second type of system here. In practice, most of my mental bandwidth today goes towards making the second type of system better.
- Ah this is fun! :)
> I know enough Hindustani music to understand that only melodies are played, and almost never harmonies. Especially when the artiste is performing alap.
I think is broadly true, but anecdotally speaking, myself and people I’ve trained under use harmony and love harmony for hardcore Hindustani classical. It’s a bit of a shame that more don’t use it, but I wouldn’t underestimate it either.
- You add it in your addendum, but I must emphasize that you are extremely biased towards Carnatic.
For context, I’m trained in Hindustani music and have given a number of performances and have family and friends who have done the same for Carnatic music. My experience is that Harmonium is very common as an accompanying/supporting instrument - probably precisely for the reasons you specified. Harmony is great, it doesn’t mimic to do the vocal variations - just support the singer doing it as well as possible.
What I’ve actually seen is that use of Harmonium as an accompanying instrument is much more common across the spectrum (both north and south) than Violin for classical and semi-classical - though unlike Violin it’s almost never used solo. OTOH I’ve never seen violin being used in Hindustani.
- Developer here. I quite like Jira, I've never seen anything as fleshed out or complete as it is. At a previous startup, I used clubhouse.io, but I seriously missed Jira after a few months.
I generally think Atlassian is a really solid company building good products and I really don't get the hatred. I'm also open to acceptable alternatives to Jira and Trello.
Edit: ooh, just saw that they also own statuspage. And everyone uses/likes statuspage.
- Great recession grad - similar numbers. That experience has really scarred me till today, especially because I kept being told how valuable software engineers are, and how good I personally was in this field.
Today, I'm simply grateful to have a fantastic job, and strive to live below my means assuming that things can go back at the snap of someone's finger.
In terms of practical advise for a new grad, there are tons of startups and enterpreneurs doing really interesting work. They need good programmers but can't afford to pay as much. This sort of place can be a great place to kickstart your career, at least for a few years, till the broader picture gets better.
- for real under-performers, it's usually clear within 3-4 months, esp in small teams / small startups. i have _never_ seen a case where i feel a person lacks fundamentals or is a bad culture fit for a team after 3 months, then turn it around 6 - 9 months.
any number of months waiting after 3-4 IME is months too late. but it feels cruel and it's tough to convince yourself you're right in a specific case. especially when you get to know the person.
- It _can_. The idea of having prototypes that can be used immediately but very small in scope, not thinking about what you're going to be working on next week right now, making sure you're setting up systems that can give you fast feedback etc, are immensely helpful for difficult problems.
Just taking the examples that are mentioned here:
> Designing an architecture for a new, ambiguously scoped system. The MVP is, can you take the top 2 most ambiguous risky part of a potential solution and script it out. Then present the operating characteristics. Anti-pattern: create a story to design an architecture.
> “Improve system performance”. Profile various aspects where you have a hunch that things are bad. Investigate theory a, b, c to improve performance. Are they trivial fixes or need a large refactor. Build up buffers for the uncertainty but react when things become more certain. Anti-pattern: "timeboxed performance improvements"
> Coordinate a rollout of a backwards incompatible change across N dependent systems. Sometimes you can't help but do a very large rollout, so alright. But one essence of agile development is to keep your rollouts as small as possible.
Just to be clear, I'm not saying these things are not difficult problems, but agile (with lower case a) development _can_ really help, if we want it to.
- I like this distinction, and the bit about converting difficult problems into hard-work.
There's one thing that occurred to me in the context of agile + difficult problems. When I think about my sprints, the vast amount of my time is spend dominated on that one "difficult" problem, which on the surface does not feel difficult. The spirit of agile development is to _try_ to transform difficult problems into hard-work (in the way suggested in the article), but I feel like most people don't try very hard to do that.
We could improve the way we structure our work by allowing ourselves to be more honest about acknowledging this, as well as actually putting in the mental work to figure out if parts of the difficult problem can be converted to "hard work".
- Interestingly, a close analogy, hate speech, is perfectly legal in the United States. It looks like laws to ban hate speech have been found unconstitutionally. This is in contrast to most of the other countries around the world.
United States values freedom of speech much, much more than any other country around the world does. Both fortunately and unfortunately. I'd expect most of the rest of the world to follow what Japan is trying to do here, or something close.
I don't know how I feel about this personally. I completely agree with you - but defending free speech is hard. When an extremely popular and influential person says (but not threateningly) that you/your family are not entitled to exist and live freely, when your country is not entitled to exist, would you support that persons right to say that?
Bullying is different though. If narrow/specific enough, causing mental and emotional distress online, must have the same level of punishment as it does when it's done in the real world.
- That's an interesting second-order effect right? Before Kubernetes et al, it was so much work or so complex that few companies implemented those things. Kubernetes saves so much work, that now everyone is doing it and it feels like more work.
"Things" here mean different things for different people. For me, it's secrets/certs, better rolling deploys and infra as code.
- I don't know... I might be having a reverse-survivor bias seeing, being in and contributing to failure, but I've _never_ seen a case where "let's increase our sales headcount" strategy actually did anything (EDIT: i.e. when things are bad. Of course, if things are good, sales is a key driver to growth)
If you need "more sales" to fix it, the problem often lies somewhere else.
To be honest, I was very confused by the the @'ing. Is it possible to always pin the current open file to the context, perhaps in a FIFO fashion? (Other than the manually pinned files). The UX around pinning / @'ing is not super clear to me.
Otherwise still getting the hang of it, and generally pretty neat.