Hacker Newsnew | past | comments | ask | show | jobs | submit | rami3l's commentslogin

I've been playing around with Zig as a potential C alternative in my stack, and I think that it's pretty good at least for toy/learning projects actually. I especially like the way `comptime` gives me superpowers.

Before Rust and Zig, I thought I disliked systems programming, while as it turned out, I mostly just disliked C.

However, when it comes to actively maintaining a serious project you do need to take extra care, since using a pre-v1 language does require a lot more efforts, since even in a post-v1 language you need to handle lib updates and such...

Also, even though I believe I'm no longer afraid of manual memory management, explicit allocators, etc. for writing regular userland applications, I still think Zig can be too low-level for certain problem domains from time to time (the same thing for C, and I believe Zig is there specifically to target C programmers), so it's really about finding out which tools would be a great fit for you in which scenarios.


Thanks for sharing the experience! At Rustup we're also getting ARM64 Windows-related requests recently, so I'm very curious about how well these machines actually do as a daily dev workstation. Looks like your Yoga 7x performs even better than I thought it would!

I'd like to add that actually there is an official prebuilt Rustup binary available for you at https://win.rustup.rs/aarch64, maybe that will lead to less translation overhead for your Rust workflow :)


Thanks for the pointer to the aarch64 build of rustup. Are there plans to update this bit of the website to point at that version in the future? https://files.wezm.net/forums/Screenshot%202024-07-16%20at%2...


The site's source code is already updated, but unfortunately the website itself is refreshed per Rustup release, so we might have to wait for a bit longer...


This reminds me of one issue that I've encountered at Rustup. Early versions of ARM64 Pi OS actually use a 32-bit userland. As a result, this has caused user complaints since our installer sees a 64-bit kernel and will happily download a 64-bit binary (which will then refuse to run): https://github.com/rust-lang/rustup/issues/3307#issuecomment...


As a current Rustup maintainer with a bit of Ada background I gotta say: nice work!

I do feel Ada as a language is way ahead of its time, but when I was learning it (a while before the first Alire release) I was also puzzled by dev environment setup. I guess the Rust experience has shown the importance of a friendly onboarding experience, so I’m very glad to see Ada is going this direction as well with Alire and now Getada :)


Many thanks for this book! Think Python 2nd is the first book I've ever read in order to teach myself programming.

Now I've come a long way to become an actual developer shipping real products and have certainly learned a whole lot more on the topic, but I still think the first steps are the most important/difficult ones. Although I've moved away from Python towards other platforms such as Rust, the basic concepts covered in this book are still very much relevant.

I'm really excited to learn that Think Python has become more modern and interactive with this update!


Rust dev here.

I really love the fact that most of the time people from the Golang community would like to say "look what I've made with Golang!" That's the sign of success: the users (here I mean general devs) should not care too much about the language per se, they still have applications to ship!

Rustaceans tend to talk more about cool new language features. They are critical to what Rust does, but maybe they have also got too much attention.


I have also encountered this quite often. I'll say the ideal solution would be "postfix streaming methods" like `.filter` and `.map`. Unfortunately, Python doesn't have those (prefix `filter`s and `map`s are not even close), and you have comprehension expressions at best. To make things worse, complex comprehensions can also create confusion, so for your particular example I'll probably say it's acceptable. It could be better if you use unpacking instead of indexing though, as others have pointed out.


The last time I gave F# a shot, I tried to write a simple Telegram bot in it.

Just to test how much I would actually benefit from the .NET ecosystem, I chose to use a C# wrapper for the Telegram API. Suddenly I had to handle null references and exceptions everywhere (it's in this regard even worse than Rust, where I'm guaranteed to get Options and Results).

I know proper support for C# T? type interop is in the works (https://github.com/dotnet/fsharp/pull/15181), but really it seemed to me that too few cared about F# to get it landed in a reasonable timeframe.

I'd really love to see a pragmatic FP language with a reasonable amount of libs to choose from (both natively and via interop without much effort), but F# was a bit far from that description IMO.


Indeed, that has been a real problem, so now you can probably write `private Dictionary<RoadPlate, List<RoadPlate>> road = new();`.


This was my main complaint, as I nlk no one the dict part needs typing, but surely `new` could infer what I want.

If so, I'm very glad.


Exactly. I recently started to write some LEAN which uses a ton of Unicode characters and I still use JetBrains Mono with ligatures on. ≠ is 1 unit wide but != is 2 units wide, so it's not that confusing as one might think.

Besides, if someone insists, it's also possible to make a language-specific setting in the editor to disable ligatures in those languages :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: