It's unbelievable that Trump has managed to facilitate this before he even steps into office. It is a brutal display of power, but that is sometimes needed, just like when a parent needs to intervene in a conflict between children.
No, the "C community" and creators aren't making a political stance on things at all. Lua doesn't either. The Zig creator is very outspoken on political matters.
Not making a political stance is implicitly embracing the status quo. That’s usually fine because most hot political issues are far away from programming language design and implementation. Others feel differently, that political issues which affect community members (or people who could become community members) are important to speak out on. Regardless, every community takes political stances, some are just more upfront about it
Andrew Kelley is just one guy and he’s allowed to express his own political opinions online, just as you are. What evidence is there that the community as a whole is “annoyingly political”?
So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python.
I'd love to see a seasoned Python developer and a seasoned Rust developer comparing the time they spend to solve e.g. Advent of Code. I bet the Python dev would solve it at least ten times faster (developer time, not execution time).
> So you basically never have to worry about lifetimes or memory management or the borrow checker?
Yes. Once you're experienced enough you naturally start writing code which satisfies the borrow checker and you never really have to think about it. At least that's how it is for me.
> Because that would be a prerequisite for it to be as productive as Python.
It's not that hard to be more productive than Python for a lot of tasks, simply because Python isn't actually the most productive language in a lot of cases, it's just the most well known/most popular. (:
I do a lot of data processing in my scripts, and for many years my default was to use Ruby. The nice thing about Ruby is that things which take 3~4 lines of Python usually only take 1 line of Ruby and are significantly more convenient to do (e.g. it has proper map/filter/etc., nice multiline lambdas, regex matching is integrated into the language, shelling out to other processes is convenient and easy, etc.), which translates into significant productivity savings when you just want to whip up a script as fast as possible.
So some time ago I started writing my scripts in Rust instead of Ruby (because I often deal with multi-gigabyte files, so the slowness of Ruby started to be a problem; otherwise I would have kept using Ruby). And I've made myself a small custom library that essentially allows me to use Ruby-like APIs in Rust, and it's remarkable how well that actually worked. I can essentially write Ruby-flavored Rust, with Ruby-like productivity, but get Rust-like performance.
In C++ I have learned the patterns and so I rarely need to worry about lifetime - everything is either on the stack or a unique_ptr. Even when I need to take a pointer I know I don't own it but my project has clear lifetime rules and so I normally won't run into issues.
The above is not perfect. I do sometimes mess up, but it is rare, and that is C++ so I don't get tools/the language helping me.
I've long been intrigued by rust for their claims on those lines. But I can't justify a billion dollars and many years to rewrite our current c++. that means anything would need to understand c++ types so I can call existing functions that need a vector or implement a virtual function on an existing interface.
We are actually looking at a different option: break up our processes and use IPC. There are architecture reasons to do this, but that means the IPC is something we can define and so some of those processes would be all new code that could then be written in rust. Others of them would be small enough that it is feasable to rewrite in rust without blowing the schedule/budget. However that still leave the vast majority of our code as C++ for the foreseeable future.
> So you basically never have to worry about lifetimes or memory management or the borrow checker? Because that would be a prerequisite for it to be as productive as Python.
To be more productive than Python? I almost never have to worry about lifetimes or the borrow checker. And even when I do, I'm still more productive.
I wrote a comment a while back on this topic; someone asked for a comparison between a little Python script and Rust. You can see both versions linked here https://news.ycombinator.com/item?id=40089906
Weird, I created an account for a family member last evening, and I didn't see anything racist at all. Without following anyone I only saw ads and some tweets by Elon Musk.
Hey, what about merging some of the pending PR's on LOAD81, one of these days? I've got a few more I'll clean up and send your way - SFXR support, for sound effects, joystick (already in the PR queue), MIDI, and a first pass at SVG ..
That's a lot of cool stuff. I'll try to merge them. It's not for lack of interest but for focus concerns (too many projects very the years). I'll also check if I can add some official collaborators to the project, so that some merging/development can be performed without any help from myself. Thanks for this message.
