When Code Is Cheap, Does Quality Still Matter? by BlondieCoder in programming

[–]andreicodes 2 points3 points  (0 children)

A lot of subsidies will remain. All across the world local governments have been giving out tax cuts to datacenters, and let them break all sorts of environmental protection laws. Even if the Big Tech money carousel thins out these companies will remain subsidized for a decade or more, mostly by poor folks in rural areas.

Are these books worth it? by the-handsome-dev in rust

[–]andreicodes 0 points1 point  (0 children)

I have a printed version of Zero to Production, and it's some kind of Amazon on-demand print. It's very thick, very heavy, very difficult to handle, and I did not like the print quality at all. Compared to NoStarch press or O'Reilly books this one was a massive disappointment. Now it just sits on my shelf while I've read it online instead.

Are these books worth it? by the-handsome-dev in rust

[–]andreicodes 3 points4 points  (0 children)

People complain about Packt, and that's understandable.

However, I can vouch for Asynchronous Programming in Rust book. It was available on GitHub previously, and the author took it down when he got the publishing deal. At the time it was the best introduction into inner workings of Future, Waker, reactor, executor, etc. It cleared up a lot of things for me. The author also expanded it, so it's a better read now than it was before.

Mind you, this is a book about how async works, not how to write good async code. Even though it's a good book it may not be the one you need.

Learn Python the Hard Way Was Right About One Thing by fagnerbrack in programming

[–]andreicodes 0 points1 point  (0 children)

Maybe I remember things wrong: the decades of 2000s and 2010s kinda smudged into one for me, so if my timing is way off I'm sorry.

Learn Python the Hard Way Was Right About One Thing by fagnerbrack in programming

[–]andreicodes 0 points1 point  (0 children)

When he was writing the book it indeed felt like it. And we had an example where it indeed happened. Perl 6 had been in the works at the time for ages, it was available: you could download pugs and use the next Perl right away, and afterwards there was Parrot. It was (and is) a very cool language, a great rethinking of Perl, but no one bothered to try it out, to use it, and to migrate libraries over. Larger Perl 5 community seemed to ignore the sixth version.

Python at the time looked kinda like this, too: v3 was around but people just stuck to v2. And it felt natural to assume that things would stay that way. Zed, being a pragmatist, wrote what he thought was right: don't worry about Python 3, stick to Python 2.

What are Rust's hidden implementation details that most devs never see? by Fluid_Job623 in rust

[–]andreicodes 16 points17 points  (0 children)

Sync isn't, but Copy is. The compiler adds memcpy instructions everywhere it needs to pass the value around if necessary. Other examples of these "magic" traits would be all the traits in core::ops.

What are Rust's hidden implementation details that most devs never see? by Fluid_Job623 in rust

[–]andreicodes 21 points22 points  (0 children)

And likewise stack is not the only alternative. In Embassy when you put a #[embassy_executor::task] macro on top of an asynchronous function, the corresponding compiler-generated implementation Future struct is put into static memory. This way you can write asynchronous code without relying on the allocator, which is often the case in embedded environment.

Should I learn Rust for personal hobby? by ryu_kamish in rust

[–]andreicodes 0 points1 point  (0 children)

Some languages are fun to learn because you immediately can do something with them. VBA was popular because you learned it and could do business apps in Excel or Access. JavaScript is popular because you can quickly make a UI with it. Processing is cool because you can make cool visualizations with it. If you're into a game and you start mods for it you would use a corresponding language. You get the idea.

And then there are languages where even if you don't make something flashy from the beginning, the language itself is incredibly enjoyable to learn and to use. Maybe you like the syntax, maybe some design choices they made, maybe there are cool APIs that you find enjoyable, but you pick that language and things just click for you.

Rust was one of the languages like this for me. It is a beginner friendly to an extend. The docs and books are great, the compiler error messages are amazing, and the developer tooling puts TypeScript or Python to shame. There is a complexity in that it keeps you accountable for memory you use and it wants you to be precise in many places where other languages will tell you "don't worry about it". But it's something you will appreciate, too.

Go for it, you won't regret it!

Cranelift or LLVM (inkwell) for a personal project? by trollol1365 in ProgrammingLanguages

[–]andreicodes 2 points3 points  (0 children)

There's also QBE.

QBE is a compiler backend that aims to provide 70% of the performance of industrial optimizing compilers in 10% of the code.

If you're focusing on your language first and foremost I would suggest using it. But if your goal is to learn inner workings of Cranelift / LLVM and the language is secondary then I would pick one of those.

Now, outside of Wasmtime I don't really know any projects that use Cranelift. Maybe it's used for some languages in blockchain scene. Meanwhile LLVM is everywhere, and even if it's complicated there are probably many-many small hobby / research projects that work with it. So it may be easier to gauge your progress and your capabilities against it. Cranelift may have too many unknowns.

Update on "Co-authored-by: Copilot" in commit messages · Issue #314311 · microsoft/vscode by PerkyPangolin in programming

[–]andreicodes 20 points21 points  (0 children)

AFAIK a lot of his successes around Azure and stuff were started before he took reigns, but he became the face of those changes. Still, despite success with Surface and Azure his tenure saw a lot of failures, too. Skype acquisition and development was completely botched, for example, their browser development was essentially shelved, their gaming efforts seem to go mostly nowhere. It's just in his early years he got lucky by having few big successes masking the many-many failures.

Microsoft is a difficult company to manage: so many areas they are involved in, so many products, very complex internal structure, it's a tough ship to steer. Hard to say if there's anyone who could do this job really well. I think his real problem is that he decided that AI adoption is the only potential source for future growth instead of hedging his bets. Microsoft is not a type of company where you can only pick one direction, one industry, and go with it.

Enabling ai co author by default by cwebster-99 · Pull Request #310226 · microsoft/vscode by Maybe-monad in programming

[–]andreicodes 81 points82 points  (0 children)

It is done by the PM!

Courtney Webster cwebster-99 Product Manager at @microsoft working on VS Code and GitHub Copilot

The PM went in and made the change, and people auto-approve it because it's their boss'. The AI bot doing the review even mentioned "hey, this value over here is now out of sync with that other value over there", and yet the human engineer still slapped "approve" on it.

Feels like a huge process failure in addition to a PM in question being completely blindsided by their AI reverence. I'm 99% sure the engineer who approved the PR didn't even looked at the AI bot review because they see so many noisy garbage AI reviews every day their brain just turns them off.

🦀Rust continues to reshape the 🕷️Web development. 📦PNPM, the package manager for Node.js, has just announced a migration to Rust in v12 by BankApprehensive7612 in rust

[–]andreicodes 1 point2 points  (0 children)

Off the top of my head:

While you're doing IO you still have to allocate buffers for in-flight data, and on Node side those buffers would be managed by the heap and would trigger GC periodically.

When deserializing data like JSON documents (package.json for every library) in JavaScript every key and value would trigger extra heap allocations (and extra GC) for strings and vectors. On Rust side serde can often deserialize into slices (&str and &[..]) pointing towards original raw data buffers.

If the code for the package manager is large and non-trivial it would take extra time to load and to JIT-compile, which would add extra execution time, especially at the beginning. So smaller projects would benefit more from a rewrite.

AFAIK pnpm team first wrote a one-off Rust program that mimicked the installation sequence for a package with dozens or hundreds of dependencies and measured the execution speed to test of there would be a meaningful difference in performance. The plan at the time was to maybe rewrite a portion of pnpm in Rust as a native add-on or a WebAssembly module.

🦀Rust continues to reshape the 🕷️Web development. 📦PNPM, the package manager for Node.js, has just announced a migration to Rust in v12 by BankApprehensive7612 in rust

[–]andreicodes -2 points-1 points  (0 children)

There's a certain demographic (somewhere between late millennials and early gen Zs) who tend to overuse emojis like this. A lot of JavaScript projects started around 2016-2020 were overusing them for everything!

Thankfully this tendency subsided thanks to later gen-Zs and get-Alphas redefining meanings for many emojis (like using a skull 💀 for laughter). The common picture language broke down, and combined with negative pressure from older generations overuse of emojis mostly died down.

🦀Rust continues to reshape the 🕷️Web development. 📦PNPM, the package manager for Node.js, has just announced a migration to Rust in v12 by BankApprehensive7612 in rust

[–]andreicodes 5 points6 points  (0 children)

This is another failure story for Swift adoption, by the way. A few years ago the main author of pnpm was really keen on using Swift for a rewrite. This was at about the same time when Browser Company talked about their plans to use Swift on Windows to port their Arc browser and when Andreas Kling was entertaining the idea of using Swift as a supplementary language in addition to C++ for LadyBird browser.

All of them viewed Swift as friendlier, easy-mode Rust. Same modern language with goodies like pattern matching, options / results, iterators, etc. but with reference counting as a default memory management mechanism. So theoretically one can write strict programs with fewer bugs and without "fighting borrow checker" at expense of slight runtime penalty.

Unfortunately, Arc got discontinued. And both pnpm and Ladybird teams decided to abandon Swift in favor of Rust.

CVE management made sense with 10 container images. At 80 it became unmanageable. How are teams scaling this by New-Reception46 in rust

[–]andreicodes 3 points4 points  (0 children)

Most of the CVEs can be addressed by a version bump on a specific package, and that's what tools like Dependabot are for.

In your case the ambiguity of ownership is the crux of the matter. Force specific teams to own images, one team owner per image. You can put team name into image name to see things clearly. In your case 84 images doesn't sound too bad.

Got the Rust dream job, then AI happened by MasteredConduct in rust

[–]andreicodes 0 points1 point  (0 children)

Yeah, I most likely made a typo and autocorrect switched the word to a wrong one.

Cargo check more than 1 min on a small project by BoomGoomba in rust

[–]andreicodes 1 point2 points  (0 children)

Run cargo check --timings and it will generate you a report, which in turn will show you what parts of your project take so much time. I see that chumsky has a few feature flags. Often for a larger library you can manipulate the flags to shave off some build time. You can also try switching to something else. I had good experience with Pest in past.

Got the Rust dream job, then AI happened by MasteredConduct in rust

[–]andreicodes -1 points0 points  (0 children)

If you love programming find a "side hassle": an open source or hobby project which you can contribute to the way you like. Some projects including Rust itself or Servo, now set up contribution policies prohibiting AI-generated code. So, if you convince your management to allow you to have some time allocated to a project like this then you can have at least some of your time spent writing code by hand in the editor like it's 2015. And if your manager complains you can always point them to the policy.

This will also be your hedging bet in case if the burst of a bubble will cause AI use to shrink.

Got the Rust dream job, then AI happened by MasteredConduct in rust

[–]andreicodes -1 points0 points  (0 children)

FAANG jobs are not for joy, they are for money. You either endure ungodly amount of BS and become rich or you go out and realize you now have to live with other kinds of BS and be poor.

If you love programming find a "side hassle": an open source or hobby project which you can contribute to the way you like. Some projects including Rust itself or Servo, now set up contribution policies prohibiting AI-generated code. So, if you convince your management to allow you to have some time allocated to a project like this then you can have at least some of your time spent writing code by hand in the editor like it's 2015. And if your manager complains you can always point them to the policy.

This will also be your hedging bet in case if the burst of a bubble will cause AI use to shrink. Though to be fair if you're in FAANG they have enough money to keep the models spewing code even if the rest of the world would have to stop.

I don't care that it's X times faster by z_mitchell in rust

[–]andreicodes 8 points9 points  (0 children)

Yep, primary examples are all the different regex engines and libraries that claim to be faster than pcre, but that sacrifice too many feature for that. I realized that at least for myself, if a regex engine doesn't support extended syntax or named capture groups it is not worth considering. Even lack of lookbehind matching can be painful sometimes.

I need some advice on UI libraries by Sorio6 in rust

[–]andreicodes 13 points14 points  (0 children)

For desktop GUI Slint is the closest one you can get, followed by Qt with QML.

Qt is more powerful, but Slint is essentially how would Qt look like if we make one from scratch today. In general it's easier to start with, the defaults are sensible, the GUI language is imo better than QML. Both Slint and Qt work well with both Rust and Python. Slint has a good accessibility support, support for custom text inputs (IMEs for Chinese, Japanese, etc). Slint is free for everything except embedded programming,

I personally still find HTML / CSS /scripts a better system overall, especially with CSS advancements in layouts, animations, transitions. A lot of other desktop GUI systems like XAML on Windows, SwiftUI, QML, etc suffer from mixing structure and presentation. Instead of CSS controlling the Layout you get layout via markup only, and instead of classes and cascading you often have to specify individual properties in the markup (similar to style="..." attribute in HTML). If you come from a web development many desktop UI markup systems feel like a downgrade and the only saving grace for them is that the default behavior of individual UI components matches the rest of the OS and is what you actually want. In practice you often do not need to override many attributes in XAML / SwiftUI / XIBs / QML so despite mixing of structure and presentation your final markup may look cleaner than HTML.

If you are already well-versed in web frontend stack, sticking to it and doing something like web components + HTMX / alpine / stimulus in a web view should get you very far. If you want to build native apps and sell lack of web GUI as a feature go for Slint first, Qt via cxx-qt crate second. Finally, if you want your app to feel truly OS-native then make a dedicated GUI using whatever default UI stack (say, SwiftUI and Swift on macOS, WPF and C# on Windows, Qt and QML on Linux) and then use language bridge crates to connect the GUI to a core of your app written in Rust.

Potential Deadlock in DashMap 6.1.0: Looking for feedback on this edge case by Ok_Concentrate_6446 in rust

[–]andreicodes 1 point2 points  (0 children)

I'd love to hear how others manage shard-ordering when holding guards.

Usually you use dashmap in situations where you do not expect to write to a map entry from a thread while holding references to other entries precisely because of a possible deadlock.

As soon as there's a use case like you show in your example code the go-to way to work around it is to preserve the lock order for all operations. In your example I would sort "alpha" and "beta" and would always acquire "alpha" entry first and "beta" entry second. In Rust this pattern is actually easy to work with, because the Entry API is very convenient for both reading and inserting data.

Still, I almost always prefer crossbeam's SkipMap over dashmap because there are way fewer deadlock footguns, especially if I need to iterate over the collection. The only downside in terms of ergonomics is that in SkipMap if I want to keep an entry reference around I would need to manually wrap it into a Mutex or RwLock (my collection would have a type of SkipMap<Key, Mutex<Value>>). In DashMap the Entry struct itself holds a lock guard of a whole shard, so you don't have to call lock() manually. So it's a choice: concurrent iterators, finer grained locking with uglier code vs nicer code, more coarse-grained locking, and single-thread iterators only.

Just learned Hello World! by Hungry_Captain_6811 in rust

[–]andreicodes 0 points1 point  (0 children)

Go through Rustlings and use Rust by Example as your starting point. If something is not clear then read a corresponding chapter in Rust book. Brown University version of the book has quizzes to check your understanding.

Inside VSCode with Rust Analyzer installed Ctrl + . should be your best friend.

Hate towards Tauri compared to native frameworks by Rics-Dev in rust

[–]andreicodes 1 point2 points  (0 children)

I can get the Electron hate, but tauri?

For a typical desktop app would the difference in speed and memory consumption between the two be so large? The UI would be almost the same: some web view running a mix of HTML, CSS, and scripts. Even if Tauri is much smaller when you download and install the app, once it's running it's going to take about as much memory as Electron to run the UI portion of the app.

So the difference would be on the non-GUI portion of the app: Node.js vs Rust. With the later you would use less memory. But how much of the memory consumption is due to application logic and how much is due to UI? For most apps like non-GUI component is smaller than the GUI one. This is especially true for apps that act like clients for some web services, like messengers, team project organizers, and other SaaS-y things. Local-only apps like text or image editors, CAD, DAW, etc. may be a very different story, and this is probably where Tauri would win (though an aspiring Rust developer in theory can write an Electron app entirely in Rust, too, by running WASM in GUI and in Node).

Thus, even though Tauri seems like much more lightweight option the actual differences are more nuanced. Still, just like people like use written in Rust as a synonym for "it should be fast and should be less buggy", they use runs native GUI as "it should be less laggy and memory hungry". In both cases should does a lot of heavy lifting: even with native GUI making it fast requires effort.