• 12 Posts
  • 70 Comments
Joined 9 months ago
cake
Cake day: February 26th, 2024

help-circle





  • I don’t know about your workplace, but if at all possible I would try to find time between tasks to spend on learning. If your company doesn’t have a policy where it is clear that employees have the freedom to learn during company time, try to underestimate your own velocity even more and use the time it leaves for learning.

    About 10 years ago I worked for a company where I was performing quite well. Since that meant I finished my tasks early, I could have taken on even more tasks. But I didn’t really tell our scrum master when I finished early. Instead I spent the time learning, and also refactoring code to help me become more productive. This added up, and my efficiency only increased more, until at some point I only needed one or two days to complete a week’s sprint. I didn’t waste my time, but I used it to pick up more architectural stuff on the side, while always learning on the job.

    I’ll admit that when I started this route, I already had a bunch of experience under my belt, and this may not be feasible if you have managers breathing down your neck all the time. But the point is, if you play it smart you can use company time to improve yourself and they may even appreciate you for it.



  • You can use the regular data structures in java and run into issues with concurrency but you can also use unsafe in rust so it’s a bit of a moot point.

    In Java it isn’t always clear when something crosses a thread boundary and when it doesn’t. In Rust, it is very explicit when you’re opting into using unsafe, so I think that’s a very clear distinction.

    Java provides classes for thread safe programming, but the language isn’t thread safe. Just like C++ provides containers for improved memory safety, and yet the language isn’t memory safe.

    The distinction lies between what’s available in the standard library, and what the language enforces.




  • Great suggestions! One nitpick:

    But in principle I find this quite workable, as you get to write your CI code in Rust.

    Having used xtask in the past, I’d say this is a downside. CI code is tedious enough to debug as it is, and slowing down the cycle by adding Rust compilation into the mix was a horrible experience. To add, CI is a unique environment where Rust’s focus on correctness isn’t very valuable, since it’s an isolated, project-specific environment anyway.

    I’d rather use Deno or indeed just for that.



  • I would say at this point in time it’s clearly decided that Rust will be part of the future. Maybe there’s a meaningful place for Zig too, but that’s the only part that’s too early to tell.

    If you think Zig still has a chance at overtaking Rust though, that’s very much wishful thinking. Zig isn’t memory safe, so any areas where security is paramount are out of reach for it. The industry isn’t going back in that direction.

    I actually think Zig might still have a chance in game development, and maybe in specialized areas where Rust’s borrow checker cannot really help anyway, such as JIT compilers.








  • Just keep in mind that inheritance is nowadays a very contested feature. Even most people still invested in object oriented programming recognise that in hindsight inheritance was mostly a mistake. The industry as a whole is also making a shift to move more towards functional programming, in which object orientation as a whole is taking more of a backseat and inheritance specifically is not even supported anymore. So yeah, take the chance to learn, but be cautious before going into any one direction too deeply.



  • Of course, I’m a user too, but I don’t think Linux’s UX is that bad. It may be bad in some areas, but it’s not bad across the board.

    I also don’t think Linux is only for developers. It’s great for developers, but it’s also great for people with only basic needs of their computer, those that don’t need much more than a browser, an email client and maybe an office suite. The UX is totally adequate for them, as evidenced by ChromeOS.

    I think where Linux lacks is mainly for the users in between, those who are not full developers or tinkerers, but do want to mess around and do so from a perspective of expectations of how things worked in the Windows world. And I won’t deny there’s a plethora of legitimate enterprise use cases for which there is no equivalent in Linux today. But those are not UX issues, those are mainly matters market support. Linux is not great there, maybe it never will be. Or if it does, it’ll take a long time.


  • First example that came to mind was actually Mac users who struggle with external monitors/projectors and things like screen sharing too. I agree they’re things that are so basic they should just work. Reality is often different even on other OSes.

    Of course if you have a Windows home and everything works and then you try Linux and it struggles with a piece of equipment, it’s easy to blame Linux. You wouldn’t even be wrong. But you are oblivious to someone else’s experience who uses Linux exclusively and everything works for them, how many of those things wouldn’t work or work well with Windows.

    Personally I’m a developer, so I care a lot about integrating parts of my development stack. A lot of those things don’t “just work” on Windows, or even Mac, so I’m happy to stick with Linux instead.