Ephera

Frankly, I do most of my searching these days directly on https://std.rs and https://docs.rs . But yeah, those are usually better as a reference than for learning.

You can look through https://lib.rs and https://awesome-rust.com , if you’re searching for a specific library.

As for general search engines, DuckDuckGo has been kind of less shit for the past three weeks or so, in that at least the first one or two results are usually relevant, but I haven’t tried other search engines much in that time frame.

Another tip is to make use Clippy. Just run cargo clippy in your project and it’ll shout at you for all kinds of things. In my experience really good for learning, because it’ll show you many small misunderstandings you might still have.

Another reason is kind of a general thing with programming language design: Go, like Java or C, has relatively few concepts in the language and stdlib. This means you’re relatively quick to have seen all of them.

But this also means that for various tasks, these concepts that were left out, would have been the right tool. For example, Go doesn’t have enums.

Generally, it’s still possible to create all possible programs, because of turing-completeness, but it will be more cumbersome and more boilerplate-heavy.

So, as a rule of thumb, the more concepts are provided by the language and stdlib, the more you have to learn upfront, but the less pain you have long-term.

I mean, to name a few projects off the top of my head:

• Firefox
• Android is migrating some of their internals.
• The Linux kernel, Google Chrome, Thunderbird are preparing to use Rust.
• Many Python programs now have Rust in there, because of the PyCrypto library.
• Fish shell is in the middle of a RiiR.

I don’t feel like there’s a ton of big, mature projects yet, because of how relatively young Rust still is, but performance-critical or embedded software will be strongly considering Rust in the future.

And like C, Rust can be used to create libraries which can be called from practically any other programming language. I expect that to give it significant growth in the future.

We currently have a student for training and had her learn Rust. After two weeks or so, she told me that she had a really hard time finding anything about Rust, and it became clear that she was really confused and thought Rust was some fringe technology that no one uses.

And yeah, no, search engines just got obliterated by LLM spam since the last time she had to learn a new technology. Seriously, I remember getting better results about Rust back in 2018, when it was really still relatively fringe…

Uhm, excuse me, that is clearly a walrus.

In this case, the colleague who had talked to the customers told me, they wanted microservices, because they’d have different target systems which would need differing behavior in places.

So, I’m guessing, what they really needed is:

• a configuration file,
• maybe a plugin mechanism, and
• a software engineer to look at it and tell them the behavior is actually quite similar.

The problem is that all projects start small, and frankly most of them die small. Aiming for microservices architecture right away is a surefire way to get the project killed before anyone would benefit off of the microservices.

One of our customers recently had tasked us with building a microservices thing. And I already thought that was kind of bullshit, because they had only vague plans for actually scaling it, but you know, let’s just start the project, figure out what the requirements really are and then recommend a more fitting architecture.

Well, that was 3 months ago. We were working on it with 2 people. Then at the end of last month, they suddenly asked us to “pause” work, because their budget situation was dire (I assume, they had to re-allocate budget to other things).

And like, fair enough, they’re free to waste their money as they want. But just why would you start a microservice project, if you can’t even secure funding for it for more than a few months?

Ah, that is what I meant with OS-level clipboard manager (in fact, that is precisely what I thought of).

Nevermind simply having an OS-level clipboard manager…

More specifically with FOSS projects, whoever puts in the work makes the actual decisions.

Like, if there’s a change that one person wants and the others actively disagree with (and it can’t be made configurable either), then that won’t happen.
But usually, there’s hundreds of features that make sense in principle. And if someone scratches their own itch, i.e. implements the feature that they’re missing, then that obviously won’t be rejected, even if it’s not the most requested feature.

So, yeah, such an idea guy would need really good ideas and present them so well, that others selfishly want to implement those ideas (and moreso than all their other ideas).

The problem is that this complexity isn’t just a one-off thing you need to get through. There’s a ton of details which matter, which you will not have thought through as part of your idea.

Many of these details, you will encounter as you write code. As in, you’ve just worked for three weeks on a feature and then realize a glaring problem in one of the details. Then you spend another week trying to find a solution. And worst-case that solution is to rip out that month of work and start fresh.

This has been my biggest learning from dabbling in gamedev for a while: Make a stupid paper model first.

Even if you spend a week glueing sheets of paper, and you don’t really even get that close to your actual idea, the more of these details you think of upfront, the higher your chance of getting anywhere (or scrapping your idea without wasting months trying to put it into code).

Well, and the other big learning was: Holy crap, gamedev is hard.

I know how to “code”. I’m a senior developer and have worked on multiple large-scale software projects.
The scope of the game I was trying to create, was laughable in comparison. As in shitty 2D, tile-based, turn-based.

I encountered performance problems like I’ve never had to deal with in my career, because it turns out the whole games industry is fueled by smokes and mirrors.
Know how ray-traced lighting is the craziest new technology? Yeah, that’s literally just a matter of hardware being strong enough that we can simulate lighting in the way it actually works. It’s conceptually simpler than the ever more sophisticated bullshitting we did beforehand.

I feel like it’s maybe a bit too much to say that it’s a trauma. The Vietnam-flashback picture is just very fitting, because the puzzle is called “Towers of Hanoi” (Hanoi is the capital of Vietnam).

Currently in a project, where for strategic and unrelated reasons, we ended up with 4 new juniors and had to hand off one senior. In a team that consisted of merely 3 people before.

So, it’s just me and another guy having to constantly juggle these juniors to push them back into the right direction and review whatever code they ended up with.
It’s so frustrating, because while I’ll gladly pass on my knowledge, the project has basically ground to a halt.

There’s so many tasks me and the other senior would like to just quickly tackle. Which should just take a few days, no big deal. Oh no, I rarely get a day’s worth of work done in two weeks. The rest is just looking after the juniors, who cannot tackle many of the actual crucial tasks.

And it’s not even like the juniors are doing a bad job. Frankly, they’re doing amazingly for how little support we can give them. But that doesn’t stop the project from falling apart.

Just had to look at it out of curiosity and man, it looks like yet another C+=1. The code samples on Wikipedia contain one of those gaudy for-loops and a ternary, as if that was still peak language design four decades after C got published.

But what I seriously don’t get: Why the hell did they develop Go then? That’s yet another C+=1, with even some design similarities to Dart, e.g. it’s garbage-collected but compiles to machine code.
Like, yeah, it wouldn’t be the first time that different teams develop competing products at Google, but what kind of culture leads to there even being demand for two C+=1s?

I would argue so, because Google has quite a reputation for killing projects: https://killedbygoogle.com

Especially with a programming language or framework, you don’t want to invest in it, only to find out that it’s going on the chopping block.

Same. At some point, I learned that the bottom-of-the-barrel garbage company, that does our IT support, is apparently one of the most successful IT support companies on the planet.

I guess, the way to get there, is to not actually provide IT support. You just have to get paid for it.

Not a difficult task to not secure a cloud setup. And if it’s publicly reachable, you will quickly find yourself involuntarily participating in an automated vulnerability scan.

I feel like you could’ve asked “what’s your favorite language?” and gotten the same responses. Like, it’s Rust for me. I could argue that because Lemmy is written in Rust, there’s already some mature libraries to work off of, but someone else could argue that for e.g. Ruby, too.

Well, the alternative to “Rust” here is not another programming language, but rather another game engine.

Because ultimately, most game engines will be implemented in either C++ or Rust, for performance reasons, and C++ itself isn’t terribly better at iteration speed than Rust.

The C++ engines have simply already invested decades into abstractions, like an ECS architecture, higher-level APIs and scripting languages. There’s nothing inherent to Rust which prevents these abstractions from being built into game engines, it just hasn’t been around for that long.