I have just downloaded and set it up to talk to Anthropic. I have some unused API credits that I've been trying to find a use for. Haha.
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.
There is pinned context on the very top where you can pin the files which you frequently use.
We will start including the open file by default in the context very soon (one of the gotchas here, is that the open file could not be related to the question you have)
From latency perspective, not really. As someone who used redislabs at a previous company, the requests got routed through the Private Network proxy (whatever AWS calls it) which minimizes any networking overhead.
You may feel less enthusiastic about it once you watch the linked video. I wouldn’t exactly call it a roundabout. That’s only what’s at the center of it.
Ok fair enough, that extra bit does make it slightly more complicated. Having said that though, I would not be fazed by this, and I don't think many UK drivers would be - because we already deal with many that have more parts. When I was learning to drive, I found a particular triple roundabout quite painful but no longer have any difficulty.
There are two skills you need to pick up to deal with any roundabout system. The first is judgement of how distant other vehicles need to be before you can enter. As a learner I used to irritate the drivers behind me by being far too cautious; on a busy roundabout you can't expect an enormous gap, so you need to know what length of gap the other drivers will expect you to take advantage of. This you can only learn from experience.
The other is to plan your route, because you need to choose your entry lane based on where you want to go. These days your navigation app will probably tell you the best entry lane.
Assuming you’re asking in earnest I would begin with S&P 600 Small Cap companies, and see how they got their starts. These are all profitable companies with various levels of earnings growth and indebtedness.
Also commercial real estate fits your criteria almost perfectly.
We canceled our prime membership several months ago and have experienced zero difference in the delivery times or the benefits from Amazon. It makes me wonder what we were paying for before.
You’re paying for all the bundled crap like Prime Video, Music, Twitch, etc. You can actually be charged more for certain items as a Prime member as well, I guess they don’t need to attract you when you’re already a loyal Amazon customer.
Btw I had to cancel my Prime three times because it kept getting mysteriously reactivated with no action on my part.
Ditto in Portland, except delivered to my door. It's interesting when these threads come up reading all these complaints, I buy stuff from Amazon on average a couple times per week and never have problems with counterfeits, used goods, not shipping speeds.
Here in Tokyo, it's almost always 2 days for me, and I don't have Prime membership. Sometimes it's even next-day.
It seems like it's only the Americans complaining about shipping speeds: probably a byproduct of the transportation network there being so bad and everything being so spread out. Their other problem is likely bad labor relations and a labor shortage.
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.
> 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.
For myself, the prospect of no-gil is interesting, in that something like my Captain's Log application [0] can be free from it; for example, I currently use a QThread to implement a JournalParser, which is basically the program's "engine" - the parser constantly reads in game events from a player journal file generated by the game Elite: Dangerous (and Odyssey), and depending on the particular event, fires off a related custom QSignal, which is then processed by whichever slot (receiving function) is listening for a given Signal.
There are other places in that application where no GIL might be quite handy.
In other words, I can see where having no GIL can be useful for GUI applications like mine.
Your JournalParser sounds like it could be implemented using normal Python threads or by an asyncio event loop without much performance problems. If I understand all it's doing is watching for events and posting a signal somewhere, so it doesn't sound like the kind of application that is CPU-bound.
I could. But I 100% take full advantage of Qt's signal and slot mechanism.
Also, in many ways, GUI applications written in Python are not so much CPU bound, but Python GIL bound. If you're writing a Python/Qt application, you have to take great care to ensure your GUI doesn't freeze when your program is performing, say, many database inserts; if you have some naive loop which performs some given operation, your nice Qt GUI will freeze right up until that operation is complete. Right now the solution is to perform such operations in, say, a QThread, and use Qt's signal/slot feature to blat a progress "report" to a handler in the `main` Python loop.
So back to what I said - no-GIL is looking quite interesting to me. Whether or not Qt can take advantage of such will be a different matter.
As a hobbyist who uses python I don't think I'll be directly using concurrency in my code, but I'm betting that over time the standard library and popular external libraries will.
To take advantage of NoGIL you don’t necessarily need to use parallelism directly. But let’s say your web server or async task executor can be more efficient at sharing context between threads.
The GIL is a bottleneck in applications that are CPU bound, e.g. machine learning, so naturally the NoGIL project is not that interesting to people writing server applications.
Of course, one may argue that you probably should not write CPU bound programs in Python in the first place, but that's another story :)
A lot of Java server based applications are multi threaded, not CPU bound, and tend to do a lot of things that generally can't work in python because of the GIL. It's too simplistic to think of this as something only of interest for CPU bound stuff. A lot of what Java applications do is of course the thread per connection style processing that older java applications still do (more modern ones would use non blocking IO and green threads). But there are also background threads doing useful work or more complex requests that fork off asynchronous work across multiple CPUs and then aggregate the results back as the response. Java apps tend to have vastly more threads than CPU cores. The exception is when things are CPU bound; then you want to minimize the context switching and end up with an number that is close to the number of CPU cores.
The GIL is not about the CPU but about enabling those kinds of things. With the current GIL in place it's very simple: as soon as you hit the global lock, everything stops until it is released. It doesn't matter how many CPU cores you have, they'll be idling while one of them holds the lock. There's barely any point in even trying to do that with the GIL in place. Forget about sharing data between threads. Mostly that's done via queues or databases in python. Removing the GIL will revolutionize a few things in key use cases for python:
- data processing & ETL
- event driven server systems
- machine learning and data science systems
They can all benefit from this and that's the reason a lot of people are pushing for this. The short term performance losses are not inherent to removing the GIL but just a necessary evil while the python developers deal with fixing the bottlenecks and a few decades worth of technical debt.
>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.
Interestingly I'm working on something like this right now and do have large shared resources which meant I had to abandon using a multiprocess strategy.
I don't see why it would be confusing though, provided the shared resources are read only.
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.
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.
> You add it in your addendum, but I must emphasize that you are extremely biased towards Carnatic.
Mea culpa. As a trained Carnatic vocalist and violinist, I let my biases through. However...
> Harmony is great, it doesn’t mimic to do the vocal variations - just support the singer doing it as well as possible.
But the harmonium in Hindustani doesn't have harmony. I know enough Hindustani music to understand that only melodies are played, and almost never harmonies. Especially when the artiste is performing alap.
> use of Harmonium as an accompanying instrument is much more common across the spectrum (both north and south)
Like I said, it's far, far more common in Hindustani than in Carnatic. If some South Indian concert uses it, it's usually for bhajans, or, like you said, 'semi-classical' or 'light music'. The violin is de jure and de facto the default accompanying instrument for Carnatic music.
> I’ve never seen violin being used in Hindustani.
Kala Ramnath, V G Jog, N Rajam, M S Gopalakrishnan (although he was much more famous in Carnatic circles). The violin is not as common as the sitar in Hindustani music, but it definitely exists, and is increasing in popularity... Also owing to the reasons I mentioned.
As a long-time fan of Indian music, I'm so happy to see how the world is catching on to the depth and value of classical Indian musical traditions, and how Indians are making their voices heard worldwide. Just a 5 years ago I don't think you would have found a discussion between trained musicians in Hindustani and Carnatic on a tech-focused news aggregator. Rock on... or raag on, and thanks for the recommendations. M.S. Gopalkrishnan was certainly amazing.
> 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.
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.
The hatred pretty much comes directly from the fact that as developers we are not the customer, just the user.
What do developers want? Not to wait for flipping ever on every damn mouse click. To be as fast and minimal as possible. Stay out of the way so I can get work done.
What does the customer (the person who selects the product and signs away company $ for it) To "manage" developers with more of the latest utter bullcrap management cult incantations that are fundamentally useless while being time expensive to developers who have just a little bit of talent. Kanban. What the actual f&^k? Seriously. Does it cost develeoper time? How much? Is it worth that time?
So yeah, bits of jira as a bug tracker were designed ok, then made worse and worse and worse and slower to run and worse I have to do what now? and slower and worse and what else is there non-atlassian like literally anything else is worth a shot.
Years ago in a fit of "do something about the misery" I looked at the atlassian website, saw "contact the founders" and thought I'd let them know how much worse this crap was getting and how much I didn't like putting up with it as a user. Some flunky created a goddamn jira ticket, then closed it! Never seen by the founders. Being an angry idiot I sent another one filing a bug that "contact the founders" is not seen by the founders so is wholly dishonest. You can guess how that changed everything.
They don't and didn't care. They hate me and my kind is the only reasonable inference I can make. What am I meant to do? Turn the other cheek so they can make more money kicking me in the shins? Yeah so there's one place the hate comes from. We are forced to use a product made by a company who hates us.
Hopefully that clears it up one perspective for you. Others may see things differently of course.
I oversee multiple teams and have one R&D team that I built. Hired every person. They are all far better coders than I. But I’m the outward face negotiating for resources. And my team using Jira helps me get them resources. I use Jira with them. I’m also pulling tasks across the board. The brutal reality is it’s my reputation that brings in money and resources. I need to effectively estimate what we can do. And Jira really helps with that.
The other teams I oversee use project management tooling too. And I see them. I’m here to tell you there are SOTA companies, led by engineers, that use Gantt charts.
I used to think the anti-Jira, anti-management crowd was inherently right. Now I’m quite a bit more skeptical of those views.
As someone who is fervently anti-jira, it wouldn't be that hard to make it tolerable. Just make it so that I can't measure page loads with a wall-clock (I've clocked multi-minute loads before) that need 3-7 clicks to get where I need to be. Don't have an abundance of weird subviews that hide half the editable fields I use for another half that I don't. Make the currently active filters clear. So on and so forth, just make it usable.
I would still think jira is a bad tool (in the same way that JNCO jeans are bad pants), but at least using it wouldn't be painful.
These complaints seem like they have a couple of potential causes.
One very common load time issue is downloading too much data at once, especially on boards. I understand some work has been done to make this better, but you may get some relief by creating new boards with very limited number of issues on it - you want the board's primary filter to be specific (eg a board just for stuff assigned to you, rather than for everything asssigned to your team).
The weird subviews tend to be configurable, and Atlassian has been moving more and more towards defaults (and locking down those defaults) for these configurations that push a specific persona/way of working. I'm sure they have data that supports those choices, and there is strong selection bias going on here, but almost all the consulting I did was trying to figure out how to work around those defaults (the simple ones you can just change!)
Probably, a lot of those issues could be fixed by your administrator - you may even have permission to fix them yourself, though that process can still be quite cumbersome and labyrinthine.
So many complaints about JIRA come down to complaints about how it's configured. Atlassian knows this, and I think they are trying to make it better, but it's a hard problem. I enjoy the endless customisation available as an admin but it takes time and effort to understand what's possible, more time and effort to design those changes, and the most time and effort to make those changes match what the teams need. It's a hard problem to fix.
Sometimes people, frustrated by this big bohemoth, will pick an opinionated tool that matches their way of working. This works great for as long as that tool keeps focused and the needs of the team don't grow.
If consultants exist for a product, you know up-front that the product is intended as an "enterprise," end-all-be-all product, intended to be bought by high-level people, implemented by middle-level people, and configured to frustrate low-level people. It's not the product; it's the implementation, and it's a misalignment of incentives. Most companies big enough to afford JIRA are going to have the same kind of middle layer that winds up making people complain about JIRA on forums like this.
Mate... Jira is ~$8 a user per month. Complain about it all you like but you can't make comments about it's affordability. It's by far the cheapest option out there given it's feature set.
I wonder if self-hosting is the performance difference. I have worked in projects with 15 years of history in Jira. And they were fine. It feels kind of slow but in reality it takes maybe three seconds to load any ticket.
But actual minutes to load stuff? That is insane and I can see where the loathing would come from.
A lot of anecdotes are possibly from some years ago where self-hosting JIRA meant a single server on-premise. You might not get a lot of resources and can be used by the entire organization. The server would be at or over capacity 90% of the time so things could take forever to load.
Self-hosted JIRA also opened up to lots of customisations and hacks, which often weren't performant.
With enough data it's possible - I remember a colleague going to a conference and chatting with some Atlassian people and they said their priority (this was probably 2016 or 2017) was getting Jira to be performant for companies with 500,000+ people. With enough users, labels, releases etc I can see Jira churning on something for minutes.
Small Jira instances usually aren't a problem. It's the ones with thousands of projects or plugins. It's the way enterprises force developers to use Jira so they can have "visibility". The problem with the visibility those corporations think they have is that it's incomplete. That incompleteness is a mixture of things:
- Jira isn't well integrated to things like GitHub Enterprise or GitLab Enterprise. Instead it tracks on a regex that mars commit history or messages. It's fundamentally disconnected from the VCS workflow.
- Enterprises want to manage visibility by team, but Jira provides few if any tools for managing multiple projects within a single Project. The data structure doesn't map to how many enterprises need to use Jira in order to do reporting.
- Many enterprises rule over definitions of p0 and p1 for anything. Local context gets rolled over by this and Jira just becomes a kind of table splattered with cards.
- Jiras query system is skin deep at best and doesn't support things like querying all issues of a given epic. Much of this is fueled by their plugin API. Do a GET request on any issue and take a look at all the null fields or objects with just pure nonsense in them.
There's probably more to this list, but the point is that Jiras problem is mostly its own doing. ZenHub does a great job of filling these gaps.
I think the problem with observability/visibility/monitoring is: you need a good internal model of the domain to have any insight. When people see a aesthetically pleasing dashboard that makes sense to them, they think they have insight.
It should be the other way around, because once you have a good mental model, you can get the data you need without it being plated for you. But the presentation fools people into thinking they have insight, so they come to depend on the tools that generate this illusion of insight.
It's not too dissimilar from powerful people being cut off from reality by sycophants and yes-people. Or managers who say 'bring me solutions not problems'. Once you outsource filtering, you lose control.
If you have good developer providing honest estimates, no data protection concerns and they diligently provide actuals agile tooling like in Jira can provide great results.
But that all depends on culture. The poster seems to be an engaged manager, pays attention to the data and uses it in a sane way and has hired a group of strong developers.
I believe misery for Atlassian products were mostly self inflicted by companies that insisted on having it on-perm and then not giving a damn about upgrades and not giving a damn about resources to maintain it.
I work with JIRA cloud for 8 years now and while there are hiccups it just works.
We use selfhosted Gitlab and I do regularly report bugs in the Qt bugtracker that uses JIRA. GitLab is light years ahead of JIRA for even the basic task like adding a links, images or searching for issues. The UI is slow and cumbersome to work with.
Lucky you, you've never used it. Slow, difficult to use, packed full of features you'd rather never have heard of that are utterly useless to getting useful things done that also persistently get in your way, slow you down, make the user interface even more difficult and are the pointy end of management idiotic policy wasting your time in the name of efficiency or whatever the hell idiot managers think they're doing with that garbage. (Not every manager is an idiot but all of them are convinced it's not them and they way they do it is just fine, "So we're updating the workflow...") Jira used to have lots of distracting "opportunities to upgrade" to additional parallel product. Do they still? Flashing notifications that when you clicked them interrupting what you were doing because it's got urgent vibes all over it, it was "you should buy this other thing!" Repeatedly. Yes and I hated myself every time while I trained myself in the knowledge that "Jira important notification means ignore" Great lesson for your team w.r.t. a bug tracker, huh?
Pick 100 things you wanted improved about it, limit yourself to just your top 100, Atlassian did absolutely none of those and yet made them all worse. Every year. And I'm sure it makes good business sense. They know who is signing their cheques, that is who they care about. And I'm also sure they're very relaxed about how developers loathe them, discount me totally and look at the rest of the comments or any time it comes up. That's their right. They can laugh at us all the way to the bank. If you had more money than your great-grand children could spend in lifetime of Brewster splurges why would you care that your users hate you? You've got far more important toys to play with.
As someone who has worked on integrations with Jira for many years, it's the length of time bugs stay open. Our customers use Jira and they have to put up with its buggy behaviour that takes a very long time to get fixed or is just marked won't fix without explanation. Every product has bugs of course, but their attitude to them is quite bad. For example, there was a bug to do with epics and webhooks for years. Then they finally fixed it, then Jira "next gen" broke it again. Couple of years later it was fixed again. I understand from some ex employees that the Jira product is quite hard to work on, which makes sense given it's lifespan.
As a user, it's ok. It wouldn't be my 10th choice, but it's not the worst tracking tool out there.
As someone who never watched Gavin+Stacey, and cannot be held accountable for James Corden, I did, on the other hand recommend to my Megabank employer, way back in the 00s that we purchase Jira. I know we spent $$$$$ on it, and therefore helped Atlassian grow into what it is today.
Back then, Jira really was good and fast compared to everything else, which was pretty much bugzilla or a roll-your-own corporate ticket system. It was also the first thing we managed to get a bidirectional link from an issue into Subversion commit messages and back again, and it ticked all the boxes for... a development team.
Then came the "let's make it a generic issue tracker" approach, so yes, "as fleshed out or complete as it is" is indeed true. They've chased every niche that they can find that needs an issue tracker but making it so configurable.
It's just a shame it's a complete dumpster fire now. Slow. The search never returns what you're looking for (Confluence is worse if that's possible), and at some point and size, you're going to need a full time member of staff to look after... an issue tracker.
This feels like we're almost at one of those moments where Slack came along and reinvented all the instant messengers, and whatsapp/discord/whatever replaced skype (or arguably MS did that all by themselves). I know the apocryphal story for start ups is 'don't write a TODO list app, or an issue tracker', but there should be a better alternative. Youtrack always feels like it should get more traction, but perhaps Jetbrains are happy with it being an MVP for their own purposes.
Sure, but they also (likely) have tons of teams maintaining and improving them. It's somewhat (but not exactly) like saying Youtube and Android are not Google's products.
I agree. I don’t get the hatred for jira. I mean don’t complicate its usage. It’s a pretty awesome tool. It’s simple. Yeah, there’s some clicking but on the whole that’s on the person owning the project to customize.
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.