Hacker News new | past | comments | ask | show | jobs | submit | more brigadier132's comments login

Standing? Their population has declined by 20% in 2 years. I'd describe that more as crawling on the ground and starving.


This type of criticism reads to me as a general hatred of what humanity actually is. Mr Beast exists because humans like to watch it. By blaming Mr Beast, you are putting the effect before the cause. There is no enlightened society that is only watching MIT linear algebra lectures for fun, it doesn't exist.


> This type of criticism reads to me as a general hatred of what humanity actually is.

No, that's really shallow. "Humanity" is a perennial struggle. If I'd be looking for a word for the lowest common denominator it would be "beastliness", to stay on topic of the thread.

That criticism reads to me as a general hatred of what beastliness actually is.


Are you arguing that the public fascination with it makes it morally acceptable? If so would you consider gladiatorial fights to the death and gruesome public executions, both of which have been massive crowd-pleasers in the past and no doubt would be again if they became socially accepted, justified by the same argument? If not, what do you think is different here that makes condemning Mr. Beast for feeding unwholesome public appetites wrong, but condemning Roman emperors for it right? Just a question of the degree of nastiness?

Personally, I think human behaviour is massively influenced by culture and that we have an individual moral responsibility to take actions that work in favour of having a healthy culture. And I see that individual moral responsibility as resting particularly on those who profit from culturally influential activities (and if Mr. Beast isn't "culturally influential", please can we retire the term "influencer"). I see arguments often made that amount to justifying amoral, or even actively immoral, behaviours by the fact that money can be made from them, with an implicit assumption that humans have no free will when it comes to money, that an action that makes money has to be carried out and that this somehow morally absolves the one who does it. I see that as a corrosive meme and evidence of a deeply unhealthy culture, not as a conclusion that follows from adopting capitalism as the primary organising principle in a society.


> Just a question of the degree of nastiness?

Just a question of degree of nastiness? Yes, competitions involving life and death are qualitatively different from competitions involving money. Something interesting to think about is that we do have ultra graphic action movies and horror movies. Are those also net negative?

> Personally, I think human behaviour is massively influenced by culture and that we have an individual moral responsibility to take actions that work in favour of having a healthy culture.

There is no human culture that I know of that was not fascinated by things like money and fame.

> I see arguments often made that amount to justifying amoral, or even actively immoral

I don't think Mr Beast is immoral and not for the reasons you state. I think you have in your mind some very judgemental ideas of what is right and wrong.

I think shows like Mr Beast and all celebrity culture is dumb. I think sports are dumb too. I don't think they are evil and I know that humanity will find a way to create variants of these things no matter what kind of insane rules society tried to put in place.


Human nature is full of self-conflict and contradiction. There are more base aspects of it and higher ones as well. This has been known up and down the ages. Vices and virtues. "You're against vice, hence you're against humans because vice is what humans like to choose!" Well, no. You can be against catering to the base urges. You wouldn't feed your dog 10 cakes even if it continues eating it. And that's not hatred of dog-ity.


It's far from perfect.

One of the biggest problems with Rust error handling is that if you want to have explicit error return types encoded in the type system you need to create ad hoc enums for each method that returns an error. If you only use a single error type for all functions you will inevitably have functions returning Results that contain error variants that the function will never actually return but still need to be handled.

Without enum variants being explicit types and the ability to easily create anonymous enums using union and intersection operators Rust enums require a ton of boilerplate.


I'm just now learning Rust, as a long time C++'er, and this was the first part of my Rust journey where I thought to myself, "Boy, this really smells--this couldn't possibly be the idiomatic Rust Way to handle functions that can produce different types of errors. I must be doing something wrong!"

For example, I have a function that takes an array of bytes, decodes it as UTF-8 to text, parses that text into an i32, and checks the int that it is within a valid range. This is not a big function. But it might produce one of: 1. str::Utf8Error, 2. num::ParseIntError, or 3. MyCustomInBoundsError. There's no clean way to write a Rust function that could return either of them. I had to bundle everything up into an enum and then return that, and then the caller has to do some "match" acrobatics to handle each error differently.

I hate to say this, but I miss Python and C++'s exceptions. How nice to just try: something and then:

    except SomeError:
        doFoo()
    except ThatErrror:
        doBar()
    except AnotherError:
        doBaz()
    finally:
        sayGoodbye()
An elegant weapon for a more civilized age.

What do I know though? I'm still in the larval stage of Rust learning where I'm randomly adding &, *, .deref() and .clone() just to try to get the compiler to accept my code.


You can still do that in rust if you want / need to:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

    fn main() {
        match process(&[0x34, 0x32]) {
            Ok(n) => println!("{n} is the meaning of life"),
            Err(e) => {
                if e.is::<std::str::Utf8Error>() {
                    eprintln!("Failed to decode: {e}");
                } else if e.is::<std::num::ParseIntError>() {
                    eprintln!("Failed to parse: {e}");
                } else {
                    eprintln!("{e}");
                }
            }
        }
    }
    
    fn process(bytes: &[u8]) -> Result<i32, Box<dyn std::error::Error>> {
        let s = std::str::from_utf8(bytes)?;
        let n = s.parse()?;
        if n > 10 {
            return Err(format!("{n} is out of bounds").into())
        }
        Ok(n)
    }
In library code though that would make it generally more difficult to use the library, so the enum approach is more idiomatic. Then that comes out as

    match(e) {
        MyError::Decode(e) => { ... }
        MyError::ParseInt(e) => { ... }
        ...
    }
etc, which is isomorphic to the style you miss. What you're perhaps missing the is that `except ...` is the just a language keyword to match on types, but that Rust prefers to encode type information as values, so that keyword just isn't needed.

I feel you on the larval stage. Once you get past that, Rust starts to make a lot of sense.


Many error types implement std::error::Error, maybe using that would make things easier.

An example: https://play.rust-lang.org/?version=stable&mode=debug&editio...


Hmm, I think I tried this a few times, but I could never get the right magical combination of dyn, Box<> and & to get it to compile.


This is true, though the issue of having error variants the function can't return is fairly overblown, because most code doesn't bother handling all error variants individually. Most of the time an error is either propagated upwards (possibly wrapped in another error) or logged. Inspecting the error variants is usually only done if you want to specially handle some of them (such as handling `ErrorKind::NotFound` when deleting a file), rather than exhaustively handling all variants.


We can disagree on it being overblown or not but I think it would be enormously useful to be able to look at a function signature and know exactly how it can fail.


They tried that in Java and no one uses it...


Lambdas broke checked exceptions. You can't declare that you throw whatever a generic lambda might throw, so they quickly devolved to "I throw nothing (only unchecked)." The "I throw everything" alternative is rarely used because it spreads virally through every caller.


Checked exceptions were strongly discouraged because they have nonlocal behavior when changing library code. If you want to rethrow exceptions you can’t handle you have to update all callers when the callee changes the throw signature. Lambdas are orthogonal.


I'm thinking of cases like Stream#flatMap where I might be prepared for what a lambda (probably a method ref) could throw, yet still can't use it because exception lists for the Stream interface methods had to be declared statically years ago.


Checked exceptions were vilified long before Java gained lambdas.


While Java usually gets the blame, it was following a precedent set by CLU, Modula-3 and C++.

Also I dearly miss them in .NET, every single time something breaks in production, because some developer didn't bother to catch exceptions, when they should have.


The ways in which a function can fail is typically the job of the documentation.


Why bother having a typed return value? That could be in the documentation too. The whole point of a type system is to help me understand what the function can and cannot do without needing to make guesses based on the documentation. It's not fatal, but it is annoying and inconsistent that Rust can do this on the happy path but not the error path.


The type system cannot capture 100% of the semantics of the function. You put what you can in there, but you also need documentation. You could provide a bespoke error type for every single function that returns an error, but that's a ton of boilerplate, and you're effectively just moving the documentation from the function to the error type (enum variant names are not sufficiently descriptive to avoid having to write documentation).

Even in cases where the error does already precisely match the semantics of the function, you still need documentation. std::sync::Mutex::lock() returns a `Result<MutexGuard<T>, PoisonError<MutexGuard<T>>>`. What's a PoisonError? That's a precise error type for the semantics of this function, but you need the documentation to tell you what it actually means for a mutex to be poisoned.

You cannot get away from having documentation. And you're free to make custom error types for all your functions if you want to, it just doesn't really get you much benefit over having a single unified error type for your module in most cases. If you have a reason to believe the caller actually does want to handle error variants differently then sure, make a new error type with just the variants that apply to this function, there's plenty of precedent for that (e.g. tokio::sync::mpsc::Sender has distinct error types for send() and try_send(), because that's a case where the caller actually may care about the precise reason), but most error values in Rust just end up getting propagated upwards and then eventually logged.


> You could provide a bespoke error type for every single function that returns an error, but that's a ton of boilerplate

If we had more typescript-like discriminated union semantics a lot of the boilerplate would go away. Throw in automatic implementation of From traits for enums composed of other enums / types and it could be pretty close to perfect.


Yeah. The error type requires so much boilerplate that I honestly thought I was stupid and doing something wrong. But nope. Just horrific amounts of boilerplate.

Then people who don’t want to engage with ThisError and Anyhow do bullshit hacks like making everything a string that has to be parsed (and don’t provide functions to parse).

I get why it is that way, but it feels icky.


> I get why it is that way, but it feels icky.

There is no reason it has to be so boilerplate heavy, a lot of it can be fixed but someone has to put in the work. The only technical reason that could hold it back is compile times.


Zig has automatic error unions. No boilerplate at all, but not just a single "error" type. The only downside I see in zig errors is that they can't hold extra data.


It's a massive downside. When I was using the JSON parser I found it very annoying that it could only tell me the input JSON was invalid, not where in the input the problem was.


Yeah I agree. I think they tend to go for a mutable parameter reference to keep track of that stuff, which is definitely C-like but kinda unwieldy.


Of course there is a reason it is this way. In lower level languages, compilers need to know the type and size of the type at compile time. This holds true even for languages with looser typing like C.

You are not going to get strict types in a low level language and also get ergonomic errors. This is fundamentally not how compilers works.


The vast majority of universities are not for profit. As we clearly observe with all government guaranteed demand subsidies, prices sky rocket.


In your 4 step process where do you blame the not for profit schools for raising tuition by completely absurd and unsustainable amounts?

If we are going to forgive student loans, tax payers should not be on the hook. The loan originators and most importantly the schools should pay since they are both the primary beneficiaries of this disastrous policy.


The cost of student loans is nothing compared to the value that those degree holders will provide. In my opinion, your first degree at a public university or community college should be paid for by the Federal government as long as you keep a certain grade average, and stick to a reasonable timeline.

If it matters to anyone, I paid off my loans entirely, but also received Pell grants.


If your opinion were correct the degrees would pay for themselves and we wouldn't be having these discussions. We have people paying $160k a year to study in fields that are increasingly having their fundamental research completely debunked and exposed as fraudulent (see Political Science and Pyschology).

There is also absolutely 0 reason these degrees should cost so much. If we want to keep a guaranteed student loan program it should be restricted in the amount that can be borrowed and it should only be usable at local community colleges that cost under $5k a year. Nothing about education necessitates spending more than that.


The degrees do pay for themselves on average. Bachelor's degreeholders have median earnings $525/week higher than high school graduates (https://www.bls.gov/careeroutlook/2022/data-on-display/educa...), which over the course of a career would cover even the most egregious student debt loads. That's precisely why it's a hard problem; we could just warn kids not to jump into the debt trap if it weren't genuinely worth the cost.


I heard an interesting fact a couple of days ago,

The median student that graduated from college starting in 2009 had more debt than what they started with after 12 years and it's only gotten worse.

So your belief that it will cover the most egregious is not true for the median student. Given that, I'm also interested in how those lifetime earnings increases are distributed across degrees.


This kind of "fact" always raises alarm bells for me. Did you hear it because it's true, or because it sounds compelling while being impractical to disprove?


Here is a source I found and repayment rates tanked after 2009

https://www.mckinsey.com/industries/education/our-insights/t...


This source strongly suggests that the original claim is not true. I don't understand exactly what the X axis is meant to be, but if we assume the 2012 number is meant to represent 2009 graduates, it seems incredibly unlikely that the median graduate has made no progress after 12 years if ~62% of them began making progress after 3 years.

(Can you come up with a story where the two numbers might be consistent? Probably, yeah. Thus the impracticality of disproving weird conditional statistics like this.)


I can't find the source for the stat I mentioned originally but the data I did find doesn't paint the rosy picture of a getting college degree with debt being an unambiguously +EV decision.


> The idea of the public university is to bring a traditionally aristocratic practice - the devotion of several years of one’s young life to not-necessarily-practical intellectual pursuits - to the middle class

The entire idea that spending 4 years learning useless knowledge is somehow valuable is completely mistaken bullshit.

Aristocrats could get away with it because they were rich but there is 0 evidence this practice brought fundamental value to them or society other than serving as an expensive status signal.


> I love a good market as much as anyone but there really are problems markets will never solve

The problem with student loans is that they are not driven by markets. If they were, absolutely nobody would give a loan to an 18 yo to spend 4 years and $160k to study psychology.


Yes, profit incentive is generally a good thing.


That's literally what eve already is.


Heh, fair enough.


Because they want to allow for transactions between players but don't want to become a bank.


...they just want to be an exchange?

CCP's entire business model is on being the financial system behind the game, where real money is converted into virtual currencies to spend on spaceship ammo. But that worked fine in EVE even without a blockchain?


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

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

Search: