hyper0perator

This is why all fast food needs to be heavily regulated by FDA and only available via prescription to limit abuse.

I agree. If alcohol were marketed for heart disease reduction, I'd have no problem with it. But it's marketed as a lifestyle product and a ton of young people with no history of drinking have started as a result.

Legality under US free speech laws. See first amendment law literature.

The phone company does unfortunately allow spam callers

Disagree. Platforms are immune to liability of their users. HN could become a platform and abide regulations like the phone company.

Disagree. Newspapers and ISP follow under this regulation. Social media networks have been able to skirt the issue. If newspapers can get sued for their content and the phone company can't, it only makes sense that this applies to social media companies are held to the same liabilities or protections.

Companies profit but citizens lose out. Those two entities should not be conflated. This is akin to the outsourcing of many industries such as pharmaceuticals and medical supplies to countries that do not have the same worker or health regulations as the US.

The visa workers are second-class citizens and exploited by companies to keep cost low. It undermines all workers and in the long run undermines all nations involved. Take the US's relationship with China manufacturing where China has some of the worst pollution and is one of the largest world polluters as they do not adhere to any of the same regulations that nations of the west adhere to.

Currently there is the narrative that the US has a shortage of talented STEM. This is untrue. The shortage is due to a skewed labor market that suppresses opportunity for US citizens in the same way that a US manufacturer wouldn't be able to compete against a Chinese manufacturer not because we don't have the technology, demand, or resources, but that the difference in regulations makes it more costly.

The shortage is false, a form of gaslighting, artificially created so that corporations and academic institutions can keep costs low and suppress wages by flooding the US market with cheap labor that also bypasses usual employment standards available to US citizens. Eric Weinstein has done some really good research into this.

'How and Why Government, Universities, and Industry Create Domestic Labor Shortages of Scientists and High-Tech Workers'

https://www.ineteconomics.org/uploads/papers/Weinstein-GUI_N...

Racket will never be a practical language, but not because it is a lisp. Clojure is a lisp and is plenty practical.

Racket was designed to teach programming to young students, which unfortunately isn't a killer app for a language even though I learned a great deal from HTDP and Racket/PLTScheme.

There have been other languages that were not lisps like Dart that utterly failed or like Coffeescript, which faded away because the space that they were trying to overtake (Javascript) was already deeply entrenched.

If you can't appreciate Racket beyond it's syntax, it's unlikely that you'd appreciate it with a new syntax. Racket is academic niche in the same ways Haskell is.

If parentheses and lack of infix symbols are sufficient to keep you away from Racket and you want much of the same level of metaprogramming and macros I suggest trying out Julia, which is considerably more practical where infix expressions and operators make sense within the numerical context: Every infix operator is a function call and has a dual syntax.

But don't please don't lie to yourself that you'd ever adopt Racket if it had infix expressions. I love Racket and I still don't use it for many practical projects because the demands of work are different than academia, which I believe are the true barriers to adoption.

Thanks for all the great effort and progress. Better error messages would be awesome, but this composable multi-thread support makes Julia even more absurdly powerful and versatile! The priority makes complete sense.

The Julia team and community are constantly advancing the frontiers of language design while grounding it in real number crunching applications. I wouldn't be too concerned about trying to have the same documentation and content approach as the Rust community as their goals were to usurp the mindshare of systems programmers (C/C++) with a novel ownership paradigm.

Looking forward to the progress on error messages.