So, send’em a dicpic and you’re in :)

considering where the garbage came from, maybe we should stop shitposting :)

(sorry for the late response, I have to get in the habit of checking my Lemmy account)

No, I get that - a stylesheet denotes a class by having a dot. A JavaScript API for adding a CSS class omits this redundancy.

I was saying that the author might not be wrong to want to avoid the redundancy in rust example as well (since it explicitly mentions CSS classes).

I mean, it is not embarrassing for you. In the browser, the CSS’s “native platform”, you add classes, via the JavaScript API, without the dot. It’s not a stupid assumption.

To have to add the dot in the CSS class name seems a bit of an oversight in the gtkrs API.

Actual programmer

I wonder if JJ anonymous branches would be something that solves this. I’ve only read about it, have not used JJ yet.

Or meet old ideological dogs like me :P

Much better integrated refactoring support. Much better source code integration support. Much better integrated debugging support. Much better integrated assistive (but not ai) support.

Vscode can do many things IntelliJ can, but not all, and many of them require fiddling with plugins.

Usually, JB is also faster (if your dev machine can run it, but in my experience most devs have beefy machines).

Zed is also lightspeed fast compared to either vscode or JetBrains’ stuff.

I would expect it to rise. I still think it’s worth it, if it’s a good tool for you. IntelliJ is really a good product, even if they do have their downsides. In a commercial environment, it’s totally worth it to buy a licence per developer, if it makes them more productive.

I don’t mind paying for tools that help me do my job. For several years I even had a personal licence for “all products pack” thing. Their IDEs do a decent job.

There are better tools for specific things, but overall as an IDE, it’s pretty good and makes you effective. And especially if you have to use Windows, it’s integrating enough tools that you don’t have to mess with the Windows crappy tooling that often.

That said, it’s still a big fat slow IDE. For a while now I’ve been using neovim my modernized Linux toolkit and for the most part, I’m happier with it then I was with IntelliJ and Goland and the rest. Happier enough to not having a licence for JetBrains any more.

And recently I’ve looked into Zed. Zed looks pretty neat so far, but it’s still under development. Once things stabilise there, I might commit to it and switch full time to Zed. It’s got a few nice things that I miss from IntelliJ, but it’s way, way more responsive.

Back on topic: I wanted to say I don’t mind paying for IDEs, if they’re good tools. But this is more of an ideological challenge and I’m always trying to keep myself from overreacting. So while I don’t agree with you in general (“don’t trust paid IDEs”), I might agree with you specifically (“don’t fall for JetBrains’ lure and Microsoft-like tactics”).

JetBrains git integration is a known mess, true.

Even this is forum-like though. It’s a forum of people talking about a topic that interests them. It just happens to be distributed.

Since when do Unix tools output 3,000 word long usage info? Even GNU tools don’t even come close…

[zlatko@dilj ~/Projects/galactic-bloodshed]$ man grep | wc -w
4297
[zlatko@dilj ~/Projects/galactic-bloodshed]$ man man | wc -w
4697
[zlatko@dilj ~/Projects/galactic-bloodshed]$ 

Why not just cd $XDG_DOWNLOAD_DIR in the first place?

did you mean smuts?

XDG specifies the capital names, but to be nitpickingly technically precise, linux systems don’t do this. It mostly is done by the distribution maintainers, and the XDG specs. A base system does not usually have a notion of anything beyond your $HOME.

Try adding a user: sudo adduser basicuser. If you ls -al ~basicuser you will see it’s almost empty, just the .bashrc (or in my fedora, there’s some .mozilla crap in /etc/skel that also gets bootstrapped).

These technologies, although archaic, clumsy and insecure

Like cars? Or phones? Those are also archaic, clumsy and insecure technologies.

One thing to add that I haven’t seen is that for big projects, there’s often nobody that could understand it all. People either get their individual components it they understand how stuff interacts, it’s very rarely expected that new people in the project, even if very experienced, can just understand everything at once.

What you said that maintainers know every single fob is very frequently not the case at all! But since they get the big picture, they know in which part to look, and with their experience, they’ll know what to look for in that part, it may seem to you like magic. It’s not, it’s just experience.

Don’t get discouraged though!

Getting into big open source projects as a junior -level can be difficult, but often isn’t that hard - a lot of projects often need help and will take anything they can get. And if your experience already partially aligns with what you’re getting into, even better. If you reach out and be upfront about it, you’ll usually get pointed in some way.

Now, you seem to only have worked on your own, with smaller code bases. That means, you don’t have a problem of code organisation. So you can’t understand a solution if you don’t know what the problem is.

So how would you go about it?

My suggestion is to maybe get the. 10,000ft overview. Also, understand the project workflow. Projects usually have specific ways of doing things - how to build, test, run things. Try to figure out how to build and run the software on your own. If you make it, that’s a great step!

Then dig into one specific component/module/part. After a bit of study, you may be able to understand that component and find a simple thing that you can change about it. If you get this far you’re golden, you’re doing more then a majority of users that software.

Now if you’re interested, you can dig more, or reach out to devs, saying what your experience is and how far you got, and ask them if you can help. And take it from there.

even if it is an earlier, yet undeteced bug, whoever found it (in this case, the cowboy), should at least log it, if not open a separate PR to fix it.