Arguable, but I don't think it's a slam dunk that replacing the multimillenial standard interface for connected text (ie. text!) with an entirely novel chain of multiple artificially separated UI widgets is either tangential or just to do with 'format'. Personally I won't read them, so at a minimum these links when unidentified merely waste my time, and presumably that of other irritated commenters here. Maybe they should be identified. My personal preference would be a large red banner with a phrase like ("Warning: this is not a real piece"). But a small less tendentious icon would also be fine!
The guideline is not that the form is not annoying - some people, like you, will find it annoying not matter what. It's that the complaints about it are boring, repetitive and corrosive to the forum just as any boring and repetitive thing is. That's very much a slam dunk of truth.
multimillenial standard interface for connected text
> The guideline is not that the form is not annoying - some people, like you, will find it annoying
I'm not arguing that the guideline can be breached when some people find it annoying. That would be silly.
I'm arguing that posting articles as trains of social media posts may not be tangential nor merely a matter of formatting. If that's the case (I agree it's 'arguable'), then complaining about them isn't in breach of the guidelines.
> This is pretty ahistorical.
Claiming that posting multiple social media objects is a mere 'formatting' alteration to our legacy of textual culture is pretty ahistorical.
complaining about them isn't in breach of the guidelines.
It is, the guideline was written specifically to address the repetitive twitter complaints - you can find this explanation in the mod commentary. Also, pretty much anything repetitive runs counter to the rubric of the forum and this complaint is very, very repetitive.
our legacy of textual culture
Our 'legacy of textual culture' contains a huge variety of formats and representations. The notion that some single one is a representative standard, let alone has lasted for millennia is not an accurate one.
> you can find this explanation in the mod commentary.
If the guidelines are unclear, and arbitrarily rule non-articles in as articles, then they must be rewritten to make the fiat clear.
> Our 'legacy of textual culture' contains a huge variety of formats and representations. The notion that some single one is a representative standard, let alone has lasted for millennia is not an accurate one.
Irrelevant, as no-one made that claim. Your unevidenced insistence on your personal take on a novel tech as inarguably part of a historical tradition is just quiet shouting. I disagree, but agree it's arguable. You think it's not arguable, because it's obvious to you, and you believe what's obvious to you should be enforced.
> Hence the clarification. Hopefully it's clear now
Nope. Just that you personally rule something as tangential that I claim is not. Your personal preferences aren't present in the guidelines (I've read them). If you wish them to be so, please rewrite the guidelines.
> You made the claim
I did not. I claimed that there is such a thing as textual articles, ie. an existential claim. I didn't claim that all text, or all articles, or all textual articles, share a single format. They exist, and claiming that something entirely different (a chain of social media objects) falls under the same head is false. Claiming that two different categories of things are, in fact, different, is not 'tangential', or related only to 'formatting'.
Oh I see the problem. No, I'm not personally claiming this, I'm trying to explain the context and motivation of the site guidelines. Here are some relevant comments from the site moderator:
The guideline is there because of the repetitive twitter complaints, I'm not making this up as a fun messageboard hypothetical. Complaining about tweets being on twitter is a well-established off-topic topic.
please rewrite the guidelines
That is impractical for a number of reasons (i.e. the guidelines can't be exhaustive and also aren't, by design) which, coincidentally is also a subject of much moderator commentary. Happy to dig it up for you if interested.
I did not.
I mean, you talked about this millennial-something standard but there's obviously no such a standard. That's all. I'm happy to accept it as a rhetorical flourish and move on.
As pvg won't permit a reply to his/her/its post, I'll reply to myself:
> The guideline is there because of the repetitive twitter complaints, I'm not making this > up as a fun messageboard hypothetical. Complaining about tweets being on twitter is a > well-established off-topic topic.
This is very obviously untrue. Almost every single thread in HN is littered with repetitive comments. Try posting anything about Linux, note-taking. Dare mention an Electron app, and if it's installed with an install.sh, then .. instant death. You'll be buried under an avalanche of near exact copies of comments that have been posted tens of thousands of times on HN.
This is manifest bad faith on the part of the mods in general or pvg in particular: an individual dislike on their part of this particular repetitive complaint, which prompted a vague guideline with plausible deniability in mind.
These aren't the kind of judiciously-applied guidelines I could willingly sign up to. Unfortunately we're not permitted to delete accounts here, so I'll remove my email address, log out, and stay out of the comments.
Comments about formatting tangents are especially repetitive and don't earn their keep by bringing anything valuable to the thread; complaining about tweet threading is pissing in the wind: people aren't going to stop threading (or boldfacing the wrong text, or setting things white-on-black background, or using 200MB font stacks, or breaking the back button) just because some person on a message board gripes about it. Beelow is a link to the 'dang comments about this, there's no uncertainty, and you should stop pretending like there's a live debate about whether HN welcomes comments about tweet threading on stories that aren't about tweet threading. It does not.
It's worth knowing that HN is a common law system, not a civil law one: there's the guidelines page, and then there's a long history of moderator interpretations and addenda, and to grok the totality of our rules, you need both. Think of the guidelines like the Constitution, and Dan as the Supreme Court.
Edit
This comment was originally snottier and stated that someone had already posted the mod comment link, but, nope, I was just wrong about that, and I do apologize. Chagrin is a powerful decongestant and so I'll be less snotty in the future.
I'm a regular user here, I don't permit or not permit things. Click on the timestamp of a comment next time to reply to it if the reply button is hidden.
This is very obviously untrue
I mean, complaining about things being on twitter is offtopic on HN which I've gone to exhaustive and exhausting lengths to explain. You can't just declare it untrue, that would be, as you say, a personal preference of yours rather than the reality.
It is a bit boring to see repetitive complaints. I suspect they just won't go away until it's made obvious from the link whether or not its worth clicking on (for those of us who won't read social media trains). Even knowing it's Twitter or Mastodon doesn't really help, because the poster might be sensible enough to post a link to a real piece.
Yes I always abandon these when I see they don't just contain a link to a blog post. You might have thought someone waxing about the merits of the web would have heard of hyperlinks (admittedly, I'm only assuming that's what he's doing as I'm not going to slog through a train of mastodon posts).
What makes you say that? In my experience, there are no 'experts' in empirical fields who are no themselves deeply and practically engaged with actual research. Being well-read does not make you an expert. Writing blog posts and appearing on YT doesn't make you an expert. Critics are not experts. To be an expert in anything you have to get your hands dirty.
Nothing I can see from this guys publications or bio make it seems like he's an expert in human fat metabolism at all, let alone a 'foremost' one. I base this on a fairly cursory survey, so I'm happy to be corrected. But convincing corrections would absolutely require details regarding what he has contributed to the field.
It may be the case that people can use simplified subsets of the language to ease their way. But when a Rust advocate says that in effect to understand lifetimes you have to read the standard library source (as is written in the forum thread linked above), because no current documentation is comprehensive enough to cover it, then you know the whole thing itself is pretty complex.
This is like saying: "You think a 64bit integer is simple? OK, let's dig into the C memory model, twos complement, overflow CPU flags, how CPU caches are implemented, architectural nuances that can lead to unsynced writes from registers to RAM, etc". In reality most people can just learn that it's a number that holds 2^64 values, not complicated. If you want to really understand integers though go read the intel manual and the C memory model specification.
Are lifetimes complicated? If you're a compiler developer who needs to consider the implications across all features and edge cases, yes. If you're learning the language and you just want to write "find me a &str in another &str but don't clone it", no, it's not complicated at all.
The vast majority of beginners can just learn "& means any number of readers and no writers, &mut means one writer and no readers".
> The vast majority of beginners can just learn "& means any number of readers and no writers, &mut means one writer and no readers".
But 'beginning' is never the hard part of learning any programming language, at least for a programmer. The hard part is going from having learned the basics to getting stuff done. Rust is harder than any other mainstream language to do that in. The writers in that thread can't even describe their mental model (NOT the underlying tech as you claim) of lifetimes without vast elliptical descriptions. And they can't point to any straightforward documentation.
I have learned multiple programming languages, of many different paradigms, and never had the trouble getting to the stage of writing useful software that I have had with Rust. I've witnessed the same again and again with all the people I know - all professional programmers. In fact I'm the only one I know who's stayed with it.
I find the denial of Rust's difficulty (and not even centred on the borrow checker - it's the use of just about every commmon library) just very very strange. Odd enough (and distant enough from the obvious, adn the experience of every person I've known) that I find it completely incomprehensible.
> Rust is harder than any other mainstream language to do that in.
I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc).
> I find the denial of Rust's difficulty (and not even centred on the borrow checker - it's the use of just about every commmon library) just very very strange
Some of us just didn’t find it that hard. Like, I get that its hard for people in theory, because I’ve seen enough people express this that I believe it must be a common experience. But my personal experience was a couple of weeks of slow progress and lots of puzzling, and then everything became much easier, coupled with a joy that most of the language is so much better designed than the previous generation of languages I was used to using (e.g. it actually has sum types, and everything is an expression - why on earth doesn’t every language work like this)
C is a simple language. Many people have quickly become proficient at it with only K&R to work from, and that is a thin book. The C language has many deficiencies but I don’t think many people would characterize it as difficult to learn among its peer programming languages. It has very few concepts that you need to learn.
C++, on the other hand, is exceedingly complex and a difficult language to become proficient in, though modern C++ is an improvement in that regard. Some of this is due to decades of legacy cruft, some is due to it being an atypically expressive systems language, all of which has been stirred together.
C is a simple language if you only want to do simple things with it (like say, numerical calculations). As soon as you want to do anything more sophisticated you find all the complexity in other languages and more comes back just as library APIs rather than language-level features.
> > Rust is harder than any other mainstream language to do that in.
> I’d argue C and C++ are both harder. It’s hard to even get these to build once you move past trivia examples (including libraries etc).
Agree I overstated that. What I mean is that, out of the difficult to learn languages, Rust is the only one whose community for opaque reasons denies the difficulty.
> Some of us just didn’t find it that hard.
Why the difference I don't know. So far everyone I know who has learned it has dropped out because they just couldn't get practical traction with it. My guess is that most people who say they don't find it hard are either longstanding C/C++ programmers, and/or are learning at work where they have immediate help & scaffolding.
What is odd is that rather than responding to difficulties with a curious "Oh, I didn't find it hard, I wonder where the difference lay", Rust advocates tend to come back with an aggressive 'proof' that Rust is factually not hard to learn (with implications we can all guess at). No other programming community frequently does this in my experience (and I have brushed against many). That community attitude itself must have causes that are worth thinking about.
I know C and C++ since the mid-90's, and have delivered several products into production with them, still have issues today when dealing with some cases where the borrow checker should be fine (from human borrow checker point of view), but it doesn't get it.
There are also these patterns one has to learn like applying references to numbers in some corner cases, e.g. func(&123), and the fact polominus is being developed shows there is still room for improvement on the borrow checker logic.
> My guess is that most people who say they don't find it hard are either longstanding C/C++ programmers, and/or are learning at work where they have immediate help & scaffolding.
Neither of those were the case for me. In fact, I'd previously tried and failed to learn C (to a level where I could achieve something useful). I did learn at work, which gave me time as I was able to work on it full time, but I had no help available as nobody else at the company knew Rust at the time.
> Rust advocates tend to come back with an aggressive 'proof' that Rust is factually not hard to learn (with implications we can all guess at). No other programming community frequently does this in my experience (and I have brushed against many). That community attitude itself must have causes that are worth thinking about.
I somewhat agree this behaviour isn't great. I suspect the cause is a whole bunch of people saying that Rust is too hard, and that the industry therefore shouldn't bother with it.
Factors I'd guess at:
- Previous experience with a language that uses functional patterns is a huge plus. Even if that's very lightweight functional patterns like you might find in JavaScript or Kotlin (past exposure to something like Haskell or Scala would be even better).
- Previous experience with C++ helps. Especially if you write "modern" C++ with smart pointers, etc as this is rather close to how Rust works.
- C experience can be a positive or a negative. If you are the sort of C programmer who is hyper aware of object lifetimes and programs carefully and defensively it'll likely help. If you're the kind of C programmer who likes to play fast and loose with safety so long as it works in practice then it'll likely hinder as you'll expect to be able to do things that you can't.
- Java/C# and other strongly OOP languages can make learning Rust harder. OOP code tends to be full of graphs of objects that all point to each other, and you just can't do this in Rust. So if that's how you're used to programming your going have to completely relearn how to structure code.
And I guess some of it's just going to be how comfortable people are with abstraction. Rust is definitely heavier on the mathier side of programming (with a sophisticated type system, etc). Personally I find that makes it easier not harder than languages like Go and C which are much simpler in this respect, as when reading code in those languages I often find it hard to pick out those forest from the trees. But from what I've seen, programmers are pretty split on their preferences on this issue, and I imagine for some people this would make it harder.
> I suspect the cause is a whole bunch of people saying that Rust is too hard,
Perhaps, though I haven't myself witnessed anyone saying it's 'too hard'. Just that people (like me and everyone I know who's tried to learn) find it 'hard'. Then we're informed it's not.
My thought about the underlying reasons was more along the lines of the Rust community's inclusion ethic. I find that entirely laudable in general. But like all ideologies it can lead to blind spots when insisted on against evidence. For example, it's even built into the (plainly false) official tagline: "A language empowering everyone to build reliable and efficient software." If someone finds Rust difficult, this creates a strong cognitive dissonance in fierce Rust advocates (for some reason so many are), which evokes vigorous denial.
> Previous experience with a language that uses functional patterns is a huge plus
My previous two 'learn for interest' languages were Clojure and Elixir. I could do more in both after a week than after some months of Rust.
In my case it's not unfamiliarity nor abstraction, but the sheer complexity that bleeds right through the ecosystem. For example: something I experience every time I try to do anything 'real': I search for the most common/recommended relevant library, go to its docs and find them utterly incomprehensible. It then takes days to glean enough to use the new library fluently. Even reading commandline args - detailed but conceptually simple - leads to a vastly complex horror of a library (I won't name names) that takes days to decipher. It's never taken me more than an hour or two in any other language. My Rust projects slow to a stupefying crawl.
For all that, I'm persisting (or rather re-starting, as my attempt earlier this year left me thoroughly demoralised) out of a combination of some real practical uses I have for it ("hard" doesn't to me in any way mean "bad"), and stubbornnes. But I'll do so without the 'help' of the community, which I find insufferable.
I write low latency Java for a living (usual finance type stuff). Our fund has started to use some Rust but I've not yet delved. I'm still trying to resolve whether it will be worth my time to do so. I'm one of those unusual people who really enjoys Java programming for the most part because it both allows you to be very productive but also offers enough sophistication to achieve really high performance.
I wouldn't let descriptions[1] of Rust as difficult to learn put you off. I'm long out of date with it so can't make confident comparisons with the Java of 2022 (2023!), but you might enjoy exploring what Rust brings to the table. It's certainly very capable, and those who become fluent with it claim the early productivity hit is eventually overweighted by the correctness/longevity of what you produce. I haven't reached that stage but have no reason to doubt the claims.
If you do interact with the Rust community, I suggest doing so in Shiny Happy Person guise.
[1] only the Rust community considers these 'complaints'
The rust borrow checker has been described in trivial terms many times. The first time I had it explained, as I recall, was as a book.
You own a book.
`&` - You can lend others the book, they can't fuck with it.
`&mut` - You can lend the book to one person, they can fuck with it
`move` - You give someone else the book, it's theirs now
Or `many reader NAND one writer`
Is this a complete explanation? No. But it's quite simple and you can be plenty productive with just this amount of understanding.
Your experience is not my experience. I used Rust for the first project I wrote as an intern after dropping out, having never used it before, and I even used it to interact with mysql, which I had never used before.
At my last company I had multiple people pick up rust in a matter of days.
I'm not denying rust as being difficult, I'm saying it's easy for some and hard for some. I found it easy, I was writing productive code on day 0 with virtually no preparation other than that I wanted to try it out. Many people find it easy. Obviously some people, many people, find it hard. Life's weird like that.
OK, simple issue that a beginning Rust user runs into immediately:
- function arguments are moved into the called function
- you can call a function with a ref, and then you can keep using it in the calling function, because there is a blanket impl of Copy for refs
- you can call a function with a ref mut, and then you can keep using it in the calling function because ... ???
Because when you pass by reference, you lend the value (or to phrase it the other way around: the function borrows the value). And so when the function’s done, it gives you the value back (because that’s how borrowing works, in the everyday sense of the word, as well as in th Rust sense)
This is either wrong or incomplete. When you call a function `f()` with some `&mut`, the callee gets a `&mut`, not a borrowed `&mut &mut`. The callee doesn't borrow the ref mut, it gets the actual ref mut, and for some time you have multiple mutable references in the same scope. How?
Because the calling function isn't using it at the time. Rust isn't proving something about the number of references in memory; it's proving something about the dynamic behaviour of the program, i.e. that there can be at most one reference actively being used to mutate it, at a time.
Hence there's no problem cloning a mutable reference implicitly, when calling a function. Notice that you can't for instance send it to another thread, however.
There are not multiple mutable references in the same scope. The mutable reference is only valid for the scope of the function `f()`. This doesn't sound like a problem understanding mutable references but a problem understanding scope.
From the standpoint of being productive in Rust, this is what you need to know:
* An object has a lifetime. This generally lasts until overwritten or destroyed at end of scope.
* You can loan out references to this object. You can either have a single &mut, xor an unlimited number of & references, but not both.
* References cannot outlast the lifetime of the object they point to.
* If you have a &mut reference to an object, you can give out another &mut reference to the same object. But you can't use the first reference for the duration of the second.
* Lifetimes can be named, and you can express criteria of the form "this lifetime must at least/most this long."
* Bonus: if you have &mut x, you can give out &mut x.a and &mut x.b at the same time. But you can't give out &mut x while such a subreference is live.
And... that's really all you need. Yeah, there's a lot more rules, and there's definitely fun edge cases around things like temporary objects' lifetimes. But there's no need to know all of that stuff. If you get things wrong, the compiler will come back and slap you in the face and give you an error message--that's the selling point of Rust, getting lifetimes wrong is an error, not silent nonsense--and your task at that point is to figure out if you're really breaking a cardinal rule (two or more mutable references to the same memory location, or references not lasting long enough), or if you didn't enforce sufficiently strict requirements for the bounds of the lifetimes. And the rust compiler is pretty good at telling you what you have to do to get necessary lifetime bounds (sometimes too good--it can suggest fixes to lifetime bounds even when such bounds are unachievable).
I'd compare this to things like name lookup and overload resolution in C++, which are actually horrendously confusing algorithms that almost nobody understands in their entirety. Yet plenty of people can be productive in C++ because the general principles are well-understood, and if you're at the point where you need to descend into the morass of exceptions and exceptions-to-exceptions, you're probably writing confusing code to begin with.
But I've never heard a C++ programmer deny that it's a large and difficult language.
I personally never really had a problem with ownership model - probably because what I was doing fell into the simple buckets. Rust's difficulty goes well beyond ownership. I just thought the Rust user forum thread I quoted was a gently funny example of the Rust community's denial: "Rust's not hard, but to get a decent mental model of the borrow checker you need to read the standard library, or if not here's 10000 words on how I think of it". I'm not presenting it as "proof" that Rust is hard - the fact that I couldn't do anything practical with it after more troublesome attempts than with any other language is plenty enough for me to know that. Neither do I think difficulty is 'bad'. Denying it can be though.
That's someone who's defining "mental model" as effectively "build a formal model of how this things worth without actually using formalism for everything." Of course everyone in that thread is coming up with very complicated stuff, because OP explicitly asked them to do so.
Yes, Rust's borrower checker is more complicated than equivalent features in other languages. If you read the writings of the Rust language developers, you'll notice that they basically admit that it's where Rust sinks its entire complexity budget, so there's no room to spend it anywhere else. But I don't think it's too complex--it's not complex enough for average developers to not be productive. I would contrast this with C++'s template metaprogramming, which I believe to be too complex for average developers to be productive (e.g., trying to write templates that switch based on the types of the parameters, especially before if constexpr).
> Rust is harder than any other mainstream language to do that in.
It's not hard, you just add boilerplate. Cloning data, using interior mutability, or adding ref counting to deal with cases where multiple "owners" can keep an object around independently.
Then removing the boilerplate is how you do optimization, once you've gotten things to work. The opposite of other languages where low-level code is the most verbose and least intuitive.
Yep, that's the standard Rust aficionado flat insistence: "You're finding it hard. You're just wrong". Yet with more learning time than I've put into any other language I've learned, I have been unable to use Rust for real (ie. beyond beginner toys). A quick count of langs I've used professionally comes to about 10; I've learned many more to play with, much more successfully than with Rust, in much less time than I've spent with Rust. This reflects the experience of everyone I know who's tried it out (I'm the last man standing, having another crack at it this year).
The cultural peculiarity of this is that, in a field that generally lauds effort and intelligence, Rust advocates uniquely consider 'hard' or 'difficult' to be negative criticism. I don't hear this from (say) Haskell or Scala programmers. I certainly don't consider difficulty a negative - it depends on whether the payoffs are commensurate, and for Rust I think they are (I'd just quit otherwise).
As I'm 100% satisfied (no matter how often I'm unconvincingly 'corrected') that Rust is indeed harder than most programming languages to learn, I can only categorise this peculiarity as denial. Denial usually has ideological origins. I'm not entirely sure what they are in this case, though I have some ideas. These do feed into a sense that although I like the language, I don't think I like the Rust community much. I get strong religious/culty vibes from it - similar to the worst of the Linux community (for the record I also am a f/t Linux user, and I think that community has moderated considerably over time).
Just to be clear, again, lots of people find rust difficult. I found it easy. Lots of people find it easy. That's interesting.
Saying "rust is difficult" is silly to me because... it wasn't for me. Saying "rust is easy" is less silly to me because for me it was, but obviously for you it will be more silly because it isn't easy for you.
You'll find that many in the rust community are in fact very very sympathetic to your view that it's too hard to learn.
> You'll find that many in the rust community are in fact very very sympathetic to your view that it's too hard to learn.
I have not found that. The very comment I'm responding to above is a correction, telling me "it's not hard", not saying on the writer's part that they didn't find it hard, and least of all with any curiosity towards any dev claiming that they find Rust hard, because that view is considered in the Rust commmunity plainly incorrect. This is what I have found, consistently in 2022. I plan to continue with Rust in 2023, but I'll probably largely go it alone.
Well I've been around Rust since before 2015 and I'm telling you that tons of people feel the language is too difficult. Maybe you haven't seen that, but you've also seen a tiny fraction of the community relative to me.
Going it alone sounds like a recipe for it being very difficult. I'd recommend interacting with the community when you have questions, it'll be very helpful.
My only point this entire time is that saying "rust is difficult" is just as wrong as saying "rust is easy". Rust was easy for me, fact. Rust was hard for you, fact. Both things are true.
Joke btw. That thread is a hilarious trainwreck - surely the final nail in the coffin for the Rust advocates who so often deny anything about Rust is difficult to learn.
I don't mean that as an anti-Rust jibe, in fact I'm planning to get back to it this year (having given up in despair last). I like much about it, and think it's tremendously practical for many purposes. But it just is a difficult language, no question.
I mean, some question. I learned Rust with 0 professional experience in any language (I learned it after I dropped out of a CS program after 2.5 years) and I found it pretty damn easy. That was in 2015 when the language was wayyyy less approachable (worse borrow checker, everything used nightly, smaller community, no book).
Easy is relative. I suspect a major reason I found it easy was because I didn't try to solve lifetime problems, I just cloned things. I also had primarily been using C++ in school so I was pretty familiar with pointers and, to some extent, ownership. Plus my initial foray into CS was driven by a desire to do exploit development professionally, so lower level details weren't scary at all.
In the case of programming languages, yes, it's relative to the difficulty of other PLs. I've learned many over the years, and found Rust by far the hardest (it's the only one that defeated me). And it's not the most different from others I've learned - lisps are far further from the common languages than Rust is.
> I suspect a major reason I found it easy was because I didn't try to solve lifetime problems,
Well yes anything's easy if you skip the hard bits. Learn C without using pointers.
I personally didn't find ownership & borrows the hardest part - in my case it's the great complexity of many of the commonly used libraries. Rust's complexity bleeds out into the entire ecosystem (a cultural thing).
> In the case of programming languages, yes, it's relative to the difficulty of other PLs.
I've learned many many PLs at this point. Rust was one of the easiest for me.
> Well yes anything's easy if you skip the hard bits. Learn C without using pointers.
That's my entire point. Rust is not hard if you learn the easy parts first. Trying to learn everything at once is not easy, no matter the language. Once the problem becomes just learning the borrow checker it's not that big of a deal. The harder thing to do is learning the borrow checker and traits and closures and blah blah blah.
Depends on what country you're in. It's illegal here in Australia, but almost universally practised regardless. The law is not in reality available to most people, nor is it by and large adhered to by business except where absolutely necessary (ie. predictably enforced). Every large company I've worked for has broken the law with impunity.
There good cause for "the law" in daily reality (as opposed to "The Law" as an abstract good) not to be held in any esteem by ordinary folk.
Saying, no, but feeling, yes. Keating's "Asian Century" version of Australia never took strong cultural hold. Our nearest neighbours PNG & East Timor are ignored except by our NGOs and spies, and few visit Indonesia other than the Bali beach resorts. A brief 1990's spurt in Mandarin teaching in schools is in decline, with European languages remaining the most popular. Australia is still by far the most Eurocentric of the post-WW2 immigration nations. And it's literally the whitest, which is why it's been the destination of choice for so many South Africans since the 1990s.
This is changing to some extent with demographics (immigration from China and India, and some generational change). But surprisingly slowly and shallowly. Few Australians know much about Asia, or even the Pacific, let alone feel theirselves to be part of it.
I wasn't suggesting it was part of Asia, rather highlighting that it was not unusual for Australia or indeed other countries to be part of continental organizations (Israel/UEFA and Aus/AFC/Eurovision) that are different from the continent they're usually considered to be a constituent of (Israel/ME, Aus/Oceania). Regardless I do not think skin tone should come into it.
My "Asia" comment wasn't really a response to you - it's been a part of internal Australian debate since the 1980's. Keating crowned the 21st the "Asian Century", and claimed Australia should turn towards Asia. My point is that never really bit culturally. Australia is geographically Pacific, economically Asian, and culturally European/American Despite self-perception, there isn't really much non-derivative Australian culture beyond some small Indigenous influence, though we're probably a century behind NZ in that respect.
> I do not think skin tone should come into it
It shouldn't, but it certainly does. Little can be understood about Australia without it (well, ethnicity at least - broader than 'skin tone'). A large part of Australia's Europe-longing comes from a historical fear of China (as a kind of stand in for people of Asiatic ethnicity).
Clearly a matter of taste then. I much prefer the extremes, and find mild weather boring. Maybe it's having grown up in England. Much happier where I live now and I'm at frequent risk of fires and floods!
You'd think so, but from his own account he's not. Pre Asahi he used Fedora because it was easy to get working and he found Debian too hard to install. Could just be dry Finnish humour.
For me personally it's much easier to install and maintain Arch based distros than Debian based ones. It is very simple and doesn't try to do everything in your place. ¯\_(ツ)_/¯
Ubuntu/Debian/Fedora and others are great if they work out of the box. As soon as some proprietary GPU or other driver gets involved it can get painful. I recently installed Fedora on latest Thinkpad with dedicated Nvidia GPU and could not get it to work properly on Fedora. Driver crashed and did not load during startup. After trying a bit I switched to Arch and while the initial setup took longer, everything works and I can actually update it without requiring to add some shady 3rd party repos or compiling essential packages after each update manually myself.
