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 :)
Why would that be and how would this affect these Arm64 compiles on GitHub?
If you compile a normal application for amd64, it will work on any 64 bit Intel and AMD machine, unless you start using specialized features, which wasn't the case in the above mentioned case.
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 :)
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!
(Funny that it applies almost exclusively to Rust folks; I never saw any negativity towards Go from Zig folks, for example).
These individuals will of course downvote this comment as well as my previous comment, because they are so deeply emotionally tied to their choice of language that they hate even mentioning the mechanism; but I don't care about my points here, instead I care much more about the truth and honesty
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.
This is an example from the linked course https://github.com/dabeaz-course/python-mastery/blob/main/Ex...:
``` # readport.py
import csv
# A function that reads a file into a list of dicts
def read_portfolio(filename):
portfolio = []
with open(filename) as f:
rows = csv.reader(f)
headers = next(rows)
for row in rows:
record = {
'name' : row[0],
'shares' : int(row[1]),
'price' : float(row[2])
}
portfolio.append(record)
return portfolio
```You have access to the entire .net ecosystem?
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.
Consider the two examples:
`private Dictionary<RoadPlate, List<RoadPlate>> road = new Dictionary<RoadPlate, List<RoadPlate>>();`
`road : dict[RoadPlate, List[RoadPlate] = {}`
Or even just `road = {}`
I prefer python simply due to needing less writing and less reading. I can think more about the program when there's less stuff to read
I'm interested in learning a lower level language a bit better. I've spent some time in Rust and C (not enough to be proficient) -- is Zig a good candidate? It seems to have a lot of interest, I'm curious about objective views on its long term progress and forecast.
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.