C++ is kind of like the Blub language. If you know C++ well enough, you can do anything you need to do, so something like Rust just seems too esoteric and weird and pretentious.
Fortunately, I spent many years using Rust recently (coming from primarily a C background) and when I'm on a project using C++, it just feels too weird and rudimentary and horribly over-complicated.
To end with a quote from the PG article:
_But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub._
Interesting. In my experience, seasoned C++ programmers grasp the advantages of Rust very quickly. Not all of them are convinced that the advantages outweigh the practical problems, but they don't deny the existence of the advantages.
Rust gives you data race freedom and memory safety and a myriad of other great correctness preserving qualities like Options, `unsafe {` and a high quality type system.
Rust is literally designed to constrain what you can do much more tightly than C(++)/Python/Lisp. That's basically the opposite of the common definition of "freedom".
You can argue that what you give up in exchange for this freedom is more valuable, but don't twist the definitions of words.
> That's basically the opposite of the common definition of "freedom".
It depends on which "common definition" you're working from. To make an analogy, both GPL advocates and MIT/BSD license advocates argue that their conception of freedom is "more free."
Rust is closer to the GPL here. By limiting certain things that you can do, you are free to do things that would be harder if you're allowed to do anything. The canonical example here is Stylo; the project was attempted with C++ multiple times, but was too buggy. But Rust's restrictions allowed the Rust version to succeed. You can argue it both ways: Rust limits certain kinds of code patterns (outside of unsafe, of course...) but that may enable you to do things that were too hard to do when there were no safeguards.
(A more generalized version of this debate is the distinction between "positive liberty" and "negative liberty," this debate transcends software.)
Yeah Rust forces your program to use certain patterns. But in return, other users can assume those patterns exist. In result, Rust is one of the best programming languages to do refactorings in that exist. You are less free to write code that can be refactored badly, you are more free to do refactors. A sensible trade in my opinion.
Rust is literally designed with the `unsafe` keyword that tells the compiler: "hey you won't be to prove this is correct, but I'm going to do it anyway, don't check it".
The restrictions merely apply to provably correct code.
I'm not sure how telling the compiler to disable the safety features so you can do your thing is unbearably limiting.
Indeed, but in a similar manner, lisp restricts you out of the low level architecture, and you operate in a higher free-er plane where most ideas will work fine. Rust constraints are mostly liberating because you're safe to assume things will work.
Yes, Rust is much easier to write and faster to learn than C++. This makes Rust better for many cases, but you can't really say it is more powerful.
C++ templates are hard to learn and understand, but they are one of the most powerful constructs we have in any programming language, I miss them when I work in other languages.
This is a good point. Rust is better than C++ in many ways but when it comes to templates and compile time optimizations then its flipped and C++ is much better. The Rust trait system also feels pretty limited too.
Though as far as compile time templates go I think Nim templates generally meets or exceeds C++ templates in most areas. But I've become addicted to compile time type ducking, which is antithetical to Rust's vision of programming.
> ""A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed."
I think was this was meant to mean was: Any citizen has the right to join their local/state militia, and keep their service rifle and uniform with them at home.
The militia is defined in both statutory and common law as essentially every able-bodied male, and always has been in the US. The statutory law explicitly recognizes that the militia is not something you "join" but is something you are.
Obviously this should probably be expanded to include women generally, but their 2nd Amendment rights are not predicated on their membership in the militia.
> I think was this was meant to mean was: Any citizen has the right to join their local/state militia, and keep their service rifle and uniform with them at home.
Seems sensible. But the court is saying that if you look at what laws were passed / in force at the time, and what courts said about them around that time, you'll see that to contemporaries of ratification the second amendment meant a right to carry arms, not just to be in a militia, or whatever. That too seems sensible. Now what?
So if a group of people form a militia, do they then as militia have right to produce let's say nuclear weapons? As those are "arms" and thus shall not be infringed. Can federal government or state control what type of weapons these militias manufacture, import and hold?
The constitution the "the right of the people to keep and bear Arms". So who owns the right? Is it the Feds? No. Is it the States? No. It's the peoples'.
While the first part of the sentence says why should care, the explicit right is owned by the people.
What people don't often consider is that one can infer that rights might be infringed. The second amendment just says, "We can't fringe this right".
DC v. Heller was wrong. Go read the context around all of the places where a militia is mentioned in the constitution. It’s a pretty clear difference from the world that DC v. Heller created.
Yea, there's a lot of history around types of militias, too (especially formal v. informal militias). The historical arguments were what got me on this: the 'prefatory' clause is pretty clearly there to point out that formal militias are allowed, and make no mention of informal militias.
The Constitution is a little ambiguous as to whether or not a citizen must join a militia in order to keep a gun at home.
...however in the absence of militias in the US today, it makes sense that even if that requirement was initially envisioned (which is very debatable), it's no longer reasonable.
It's historically interesting to note that different versions of the amendment were ratified, both including and not including that last comma.
Fascinating. I could explain, in detail, every single much-better-known-by-men word. I did not recognize a single better-known-by-female word, with the exception of doula.
I read this with the same pleasure one would read a well-written short story. The author's English teacher would have given him an A.
However, no one should confuse this with actually being some kind of analysis. This piece is entertainment to be enjoyed by white folks in Alexandria cozy on their couch with their cafe-au-lait.
Source: Decades-long resident of DC who walks and bikes those routes every month.
>This piece is entertainment to be enjoyed by white folks in Alexandria cozy on their couch with their cafe-au-lait.
Or the Asian and Indian folks who increasingly make up NoVA’s “front row” communities. Source: growing up in Alexandria and living there for a decade.
There are elements of truth to the author’s racial generalizations, but one defining aspect of NoVA and DC is how different groups and races intermix (my middle school was more than 50% black and Hispanic, my high school more than 50% Asian). This aspect is entirely absent from the author’s just-so analysis.
It seems like IBM has blown their credibility so many times. As soon as I saw IBM mentioned in the lead of the title, I knew what was to follow is almost entirely actual-content-free marketing spin.
This is an incredibly important contributor to all of this.
At a prior company, in order to be promoted from associate to senior staff, you had to demonstrate and be evaluated performing at senior level while associate for a year. In order to get hired as a senior, you just talked with a hiring manager and an HR rep, checked off some boxes based on a few blurbs about what you did at prior jobs, and boom, you were a senior. Same thing with getting a raise. To get a raise to 150K (just as a randomly selected round number), it was an enormous bureaucratic process going up 5 levels of management that would take months with lots of aggravation - and unlikely to really pan out. To get hired at 150K for the same role, it was a couple phone calls with an HR rep and hiring manager - about 15 minutes in total.
On the subject of money - the other issue is that new hires, being certified as better than average in that role, are getting compensation packages in the top half of that band. The people getting promoted to that role are in many cases getting nothing or maybe a few thousand extra that vests in 24 months, because the stock appreciation on their N-level compensation package has lifted them into the bottom of the N+1 payband even before they were promoted.
Agile, "SCRUM", and daily "stand ups" are the worst thing to have happened to me during my career. In the mid 2010s they started to become a serious thing, and my career/work satisfaction really steadily declined.
Now, I only work in teams and projects that are pointedly non-Agile, non-SCRUM, without anyone holding a title of "SCRUM Master". My love of software development is coming back, and it really feels great.
Every time I interview for a job, the only time I permit myself one foul-language word, is when I make the point that "I'm not going to work in an Agile team, I'm too old for that shit". When what follows is an awkward, silent few moments, I know it isn't going to work out. When what follows is enthusiasm and agreement (happening more and more these days) I know we're on the right track to do great work together.
I've also hated that trend. Ill preface this with the caveat that I'm extremely biased against PMs.
What we've seen is the birth of a new profession, "Project Manager" (Agile/Scrum); and its filled by a ton of people who read a travel brochure size sheet of paper detailing how to be one and that's how they all operate, all while demanding outsized pay for the "skill" (really if they were paid minimum wage that's still too much)
They take zero consideration for team structure, working dynamic, the business that the org is operating in and tries to shove every uniquely shaped team into a square peg.
What's more annoying is that I've seen some hardcore PM run shop promoting project managers into people managers, often overseeing highly technical teams while they themselves not being technical which leads to all sort of pain and cost to the the ICs they oversee.
Agile has managed to 'codify' middle management, very poorly.
Agile is exactly the corporate management hellscape that, circa 2000, the Agile Manifesto authors explicitly sought to subvert. Things from Office Space (1999) have come exactly full circle.
I agree w/ you broadly but I want to add a counterpoint that a great PM/TPM is worth their weight in gold.
We lost one on our team and immediately we were worse off. Having someone who can unblock engineers by making and updating trackers, knowing who to talk to to get projects unblocked, and having a larger view of things sped us up so much. (Which I'm sure is why he got ferreted away to a very important project for the company ;)
> without anyone holding a title of "SCRUM Master"
I always wondered why small teams need anyone dedicated exclusively to be a "scrum master". Outside regular meetings and checking the project board once or twice a day, what is their purpose?
Galois is a bit of an interesting and unique company I've followed for some time. Really interesting work in trusted and formally verifiable systems. But I can't shake the sense that there's a lot of bark but little "bite" -- Many of the utilities they release as open source seem half-baked; requests for more information (not even tech support) went unanswered; got rejected email notifications for listed email addresses. I've been wanting to incorporate their tech, but often feel their goal is to mostly to satisfy DARPA program managers, rather than be used in-the-field.
I'm sorry you've gotten that impression. We do have some things we'd be interested in getting more users for, but much of what we build is prototypes. If you're interested I'd love to talk.
I wish I could give you more than one upvote here.
PSA: I'd also like to point out sometimes people who are smart but suffer from anxiety or depression concoct elaborate philosophical systems in order to rationalize their maladaptive thoughts and behaviors.
For all readers who have anti natalist passion: Depression and anxiety are so common now, please get help if you need it. Please do so before diving into philosophies or movements that reinforce depressive, morbid, or otherwise unhealthy views and actions, like antinatalism
Do you remember the Paul Graham essay on the Blub programming language? (http://www.paulgraham.com/avg.html)
C++ is kind of like the Blub language. If you know C++ well enough, you can do anything you need to do, so something like Rust just seems too esoteric and weird and pretentious.
Fortunately, I spent many years using Rust recently (coming from primarily a C background) and when I'm on a project using C++, it just feels too weird and rudimentary and horribly over-complicated.
To end with a quote from the PG article:
_But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub._