tene

On its own it's not necessarily an issue, but I'd consider it a warning sign. The times in my life that I've obsessively played games like this have been times when my emotional health was suffering. I felt overwhelmed by life and the world, and games like this gave me a synthetic feeling of progress and accomplishment, gave me something extremely simple to do that I couldn't fail at. Games like this were a symptom of my problems at the time, not the cause, and when my life got more stable, I lost interest in playing them.

If they're playing in moderation, just to pass the time during otherwise-boring events, probably not an issue. If they're pretty much always playing, or if it's intruding on their life, or if they're not otherwise engaging with the world, consider worrying about their emotional health.

  Location: Sunnyvale, CA (San Francisco, Bay Area)
  Remote: Yes
  Willing to relocate: No
  Technologies: Rust, Python, Go, Kubernetes, Docker, Puppet, Linux, Networking, SRE
  Résumé/CV: https://github.com/tene/tene-resume/blob/master/sweeks-resume-2024.pdf / https://www.linkedin.com/in/srweeks/
  Email: tene@allalone.org

I like this one for VSCode: https://marketplace.visualstudio.com/items?itemName=RobbOwen...

You've got it exactly right, many people in the US care far more about compliance with and respect for authority than they do about rule of law.

The way it sounds from reading the article is X11's design fundamentally is that bad for modern hardware, which is why almost all of the active graphics development is focused on reimplementing a designed-for-modern-hardware replacement. The claim from the article is that X11 is basically unsupported abandonware, and is calling for developers to please help with the rest of the work in finishing the migration of use-cases to Wayland in order to help the whole ecosystem be able to abandon the sinking ship and move to a more-modern better-maintained future.

Lifetime analysis matters a lot for way more than just garbage collection.

File handles, iterators, mutex guards, database transaction handles, session types, scoped threads, anything where ordering or mutual exclusivity matters.

What are some examples of sound programs you want to write in Rust but are unable to write?

I've struggled quite a bit with problems that feel similar to your description. This book is what helped me the most: https://www.carolynspring.com/shop/unshame-paperback/

Daily life feels like that swim scene from Gattaca.

I've not got enough of a problem to go get diagnosed or medicated.

Hmm...

Policy Prediction Markets.

I understand that you're not personally advocating for this position, but I'm glad you brought it up, because I really resent this kind of "Here's an imaginable scenario where this would have some negative consequence" argument.

Yes, if the regulators stop doing their job well, and there's a sudden extreme emergency requiring some kind of action that regulators have not already approved for use in emergencies, then there will be some costs, and sometimes those costs can be measured in lives.

This is true, but all it says is "there is some nonzero chance of society paying some nonzero cost". These costs are what we are paying in order to have a well-regulated intelligence service. The bet is that the expected risk from an effectively-unregulated intelligence service has worse costs for society than one with effective regulation.

In order for "think about the children" to be a meaningful argument, you need to actually establish that the nightmare scenario is meaningfully more likely than overreach and abuse of power that causes similar or worse costs for society.

Has this kind of "We could save the children if only we could get regulator approval to tap this phone line! Unfortunately, the regulator is taking a nap, so we're forced to let the children die." scenario actually been happening? If so, is there any kind of much-more-specific permissions that could be granted by the regulators to address the actual emergencies that have been coming up?

I kind of get "You can't trade off a life!" for some kinds of arguments, but we're talking about national security issues, and failures of corruption and overreach also involve risking lives.

"We need to just drop all safeguards and trust our valiant heroes" only works if the people who are subject to regulations actually are pretty reliably valiant heroes, or there are other significant incentive and oversight mechanisms to rely on. I don't have personal experience with people who work in national intelligence and security, but I haven't ever heard anyone willing to say that people in this line of work are consistently virtuous and corruption-resistant. There are good individuals, certainly, but there really are also both selfish individuals, and well-intentioned-but-misinformed individuals who can do a lot of damage.

I disagree.

While I agree that I haven't seen specific criticisms of Khan Academy being dangerous, I absolutely have seen both pervasive media messaging as well as real people in my personal life express and stand behind unconditional unqualified statements like "Screens are bad for kids; one way I keep my kids safe is absolutely minimizing all exposure to screens. Screens are bad and harmful for children."

This really is a meaningfully different message from "I'm concerned about social media use specifically. I try to limit the amount of passive content consumption my child is exposed to, and I try to shift the passive content to forms that are less of a superstimulus and more intentional, like novels."

I agree with you that the addictive nature of social media and other infinity pools of content and engagement represent a lot of the real danger of screen time, but I disagree that this article is arguing against a straw man.

If you're lucky enough to never encounter these ideas, congratulations on cultivating an excellent social environment! The rest of the world hasn't all made it there yet.

They had no choice? Really?

Check out this archived post from when they took down their photo sharing site: https://web.archive.org/web/20180327235711/https://lytro.wuf...

If they actually wanted to build a popular product with significant longevity, they could have done FAR more to enable people to build on their file format etc.

This "they didn't want to pursue full vendor lock-in at every step of their company; they had no choice" apologism just doesn't stand up to any scrutiny.

More likely, they made a bid to capture a greater share of the value, at the cost of limiting the size of their market, and it predictably failed. Or maybe they were prioritizing some kind of acquisition, over building a company with real longevity.

I don't really know anything about the company besides a short skim through Google, but it just doesn't seem remotely plausible to me that they really truly wanted to make this accessible to more people and cultivate a larger market and ecosystem, but somehow had literally no choice in pursuing their vendor lock-in strategy.

They chose to bet on control over mindshare, and this had predictable consequences.

How would you expect the response to something genuinely better to be different, in a non-culty way?

It doesn't baffle me; it seems pretty obvious.

Given that huge populations are consuming sugar water daily, and given the health consequences of this, information on which type of sugar water has the least-bad long-term effects is extremely valuable for harm-reduction efforts.

If "everyone should just stop drinking soda" was actually a strategy that worked, then the problem would have already been solved. It didn't work, or hasn't worked yet, so it's worth trying to check whether the variations advertised as less-harmful are actually less-harmful or not.

I desperately wish there was a country I could move to where civilization actually invested meaningfully in things that actually matter.

Having worked in SV for so long, it's hard to really imagine what this would actually look like.

What are some examples of important work with decent pay in an inexpensive area that a SV tech worker could be good at?

If they don't want to bother with leap seconds, why are they even using UTC? Why can't they just use TAI instead?

For most people working a career as a programmer, how much of their time in that career is going to be spent as an inexperienced beginner programmer?

I agree that Rust is a professional tool, designed for professional use. It's designed for professional use, instead of being optimized for inexperienced beginners like Python is.

I just don't really see "inexperienced beginners can easily contribute productively to this code base" as something that would have been valuable for any of the professional work I've done over the past couple of decades of my career.

If you're an amateur, or if you're programming recreationally, or if you're writing some low-reliability low-impact throwaway code, sure, it's great to use happy-path-oriented languages. When you want to write something that people actually rely on to run a business, you should use professional-grade tools instead.

We already have a way, reference counting and locking, the same way it's handled in most dynlangs.

I am also not a biologist, but I apparently think I know some of this? Hopefully if I'm wrong enough, a real biologist can correct me. :)

I think we're still very far from arbitrary genetic editing and whole genome design and synthesis. I don't know how much of this is "technically feasible but way too expensive" vs "we have promising research directions on some of the challenges, but definitely don't know how to do this effectively at all", but it all adds up to that not being an option today.

The best we actually have available today is embryo selection. We don't know exactly what phenotype each embryo will express, but we've got enough statistical clues that we can make fairly good guesses most of the time. So, you make 100 embryos, sequence their DNA, then choose whichever embryo is given the best score by your statistical analysis, and use that one.

Embryo selection is far from perfect, but it lets you avoid any genetic conditions that we know how to detect, and it lets you get an embryo with more of the preferred variants of genes statistically correlated with whatever you want to select on, and it's absurdly cheaper and more efficient than alternatives like "Let each embryo grow for 30 years, then evaluate the results of the genome".

With iterated embryo selection, the idea is that instead of one large batch of 100, you do a small batch of 10, choose the best from that group, and use that as source material to make another batch of 10. This acts as a ratchet, letting you get more selection with fewer embryos.

So, the point of finding an input to a function on a computer that gets a good score is that it's the cheapest, most efficient way we know of so far to get a human embryo whose genome scores highly on this function. There are also some other nice properties, like having the embryo be highly correlated with the genomes of the parents, which a lot of people like, and is something you can explicitly add to the scoring if you want.

Just like any selection/optimization procedure, you can get some pretty bad outcomes when you go to extremes, as for a lot of traits, your function on the computer is only a statistical model of observed correlations, not a real comprehensive model of what the genome means and does. I imagine you're probably going to get something with severe issues if you tried to grow the embryo you get from 10,000 rounds of IES.

Embryo selection is trying to use what we think we know to choose the best embryo, given only the genetics. We don't have perfect knowledge, but we do have some knowledge, and we can make some bounded use of it.

I do in fact plow unthinkingly into using concurrency quite frequently, and it works out quite well. I just unthinkingly use techniques like "just throw it in a dedicated thread", "put each stage in a thread, move objects between threads via channels", and "Pin one thread each to N cores, distribute incoming events across threads" whenever they seem like they might make a thing good, and they keep working out really great pretty much every time.

If you're writing C, you're going to have a bad time, but we've built some really great tools with modern type systems that make it far easier to treat concurrency as a thing that you can just rely on being able to safely use.

When you're using a language with misuse-resistant core primitives, like structured concurrency, and like Rust's Ownership, Mutex, and Send/Sync traits, it really is a meaningfully different programming experience. You make small use of concurrency all the time, because you just know by default without investing any time at all to check that you haven't made any kind of dumb mistakes.

When you use concurrency all the time, and get instant feedback from the compiler describing the precise data dependency that would make your idea a dumb choice, you get a ton of real direct feedback to learn about how to use concurrency correctly, and what designs it's a good fit for.

I agree that concurrency isn't a replacement for checking for algorithmic improvements, profiling and tuning your memory access patterns, using probabilistic filters, caching, etc. But just like how you can just unthinkingly drop a probabilistic filter before hitting a DB, I think you can and should be able to just unthinkingly spread a bunch of work out across a bunch of cores. This should be a simple, obvious, normal thing that people do by default whenever they care at all about performance, and it can be with good safe tools.

There are things that are actually vaporware. It is reasonable and normal for people to actually say when they believe that something has a lot of signs of being vaporware.

Are there really, truly no tools that you personally recommend against using?

Yes, it's very different. Xe is predicting that V will die in obscurity, and recommending that people ignore it due to that prediction. Look at the second half of that comment:

There are good ideas there, but if you sell someone the moon and give them a block of cheese that's kind of a scam.

Xe says "There are good ideas there". What do you think the metaphor of being sold the moon and receiving a block of cheese was intended to express? What does it mean to you? To me, it very clearly expresses that the language described by V's marketing would be extremely valuable and desirable, and that Xe is disappointed that V does not live up to what they expected. It's bizarre to me that you somehow see this as consistent with "should die".

What is your evidence that there's a conspiracy? Why do you believe that people are secretly coordinating on secret plans to destroy you?

Everything I've seen is completely consistent with individuals disapproving of what they see as you repeatedly claiming that V is far more capable and ready than it actually is and ignoring others who point out their perception of the same exaggerations.

I'll be curious to read your upcoming blog post about this topic, as I have yet to see you describe any justification for your conspiracy claims besides you finding it implausible that people could actually disapprove of how you talk about your work.

The blog posts that you keep claiming are maliciously-motivated conspiracy seem entirely normal criticism to me. They describe their goals and motivations, and those goals and motivations seem like very normal and reasonable motivations that explain the content of the blog post. I don't see anything that would need speculated malicious conspiracy to explain it.

If making sure references are valid is left up to the user, it's ridiculous to call this language safe.

I tried to find the source of the "V has to die" comment, and I see that you linked this in a previous claim that Xe said "V should die": https://news.ycombinator.com/item?id=27442724

Actual quote from this comment:

  Personally I think it is something that should be ignored until it dies into obscurity
  There are good ideas there, but if you sell someone the moon and give them a block of cheese that's kind of a scam

If you accidentally make a mistake when setting an array length in V, your program can read from uninitialized memory, as discussed in this article. This program, quoted from the article we're discussing, is accepted by the V compiler, and attempts to read from uninitialized memory:

  fn main() {
      x := []&int { len: 10, cap: 0 }
      println(x[4])
  }

This does not apply to every other language. The specific problem is that V lets you directly adjust the array length without doing anything to ensure that the array capacity is at least as large as the newly-specified length. Go's `make([]int, len)` ensures that the produced array's capacity is at least len. Go does have some memory safety issues (data races), but this specific issue is not a problem that Go has.

Can you link to such examples in V documentation?

I agree with the article we're discussing that the "Safety" section prominently displayed on https://vlang.io/ immediately after the header is significantly overstating its case. Here is the list, each item of which is discussed specifically in this blog post, with minimal source code you can run to check their work:

  - No null
  - No undefined values
  - No undefined behavior
  - No variable shadowing
  - Bounds checking
  - Immutable variables by default
  - Immutable structs by default
  - Pure functions by default  --  This has since been removed from the list, but was present when the author started this review: https://web.archive.org/web/20220305171852/https://vlang.io/
  - Option/Result and mandatory error checks
  - Sum types
  - Generics
  - Immutable function args by default, mutable args have to be marked on call
  - No global variables

"No Undefined Values" is misleading because the compiler does not actually prevent reading uninitialized memory.

"No Undefined Behaviour" is misleading because the C code generated by the V compiler does include behaviour that is undefined according to the C language standard.

"No Variable Shadowing" is correct; the V compiler rejects programs that would shadow variables. I don't actually see this as a benefit, as I use shadowing all the time, but it's an accurate statement about the current V compiler.

"Bounds Checking" is mostly correct, but slightly misleading because the bounds are exposed to your code, and it's up to you to make sure you manipulate them correctly.

"Immutable variables by default" and the other immutability points are misleading because functions that accept immutable arguments can still mutate those arguments.

Compared to languages with real mutability tracking, this is far less helpful in designing misuse-resistant APIs, and avoiding hard-to-diagnose bugs caused by unexpected mutation.

"Pure functions by default" is misleading because the V developer has chosen to use their own special nonstandard meaning for "Pure" that includes IO, and because of the mutability tracking not actually being effective.

"Option/Result and mandatory error checks" is correct and fine; I have no problems with this.

"Sum Types" is kind of okay, but they look kinda janky and limited. This article's example of sum types not being able to hold references is pretty concerning.

"Generics" is kind of okay, but it similarly is a very early very limited implementation.

"No global variables" is just false. V has "constants", which are just "immutable" global variables, and as we've already seen, V's "immutability" is very mutable.

This blog post also addresses the "Performance", "Fast Compilation", and "Innovative memory management" sections of https://vlang.io/.

Broadly speaking, https://vlang.io/ seems to very clearly present the language as one that is suitable for use today. I don't see anything on the main page of https://vlang.io/ that says anything even vaguely similar to "This is a very early language, these features are aspirational but still very much under serious development, and there are many known gaps we have not built solutions to yet".

By my personal standards of epistemic integrity, the front page of https://vlang.io/ is misleading and dishonest. I recognize that many people consider this kind of "marketing" to be acceptable, and I'm fine with letting people do that as long as they're not complaining about people actually checking their claims.

I really love the ambition of V, and I would be very happy to use it if it were actually production-ready. I have sometimes used early-development tools in production when I've had a good understanding of what the actual gaps and deficiencies and defects in the under-development software are. V's aggressive marketing that goes out of its way to avoid discussing its weaknesses means that I can't actually rely on what I read from them about the language's suitability for high-reliability use. When someone shows me that they're happy and willing and eager to mislead people about the flaws in something, then I believe them!

To me, these posts seem to be written from a perspective of eagerly wanting to use the language that seems to be advertised, and being disappointed at the big gap between the marketing and reality. The two big messages I see in these blog posts are "Here are problems I found that make me concerned about using V" and also, separately, "V appears to be marketed as if it were a polished product suitable for production use, and that's concerning, given the problems found."

Notice the end of this post: "At this time, I would not recommend spending time on V. I would also be very cautious when taking claims made by the authors at face value."

This author explicitly says "At this time" they don't think V is suitable to rely on or will be soon, and they encourage skepticism when interpreting claims made by the author. This does not read at all like someone hateful to me. This very much reads like someone who really wants a production-quality V language to use, and hopes that the project someday succeeds.

You've misunderstood my intent. In "I checked several notable claims, and most of them are false", I was trying to say that most of the notable claims that the author decided to check were false.

This is very different from saying most of the statements on the website are false, which would be a completely absurd accusation, as you correctly point out.

The summary section is literally a list of specific claims and the author's evaluation of these specific claims: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html#summ...

My comment was refuting that these posts are not "frothing at the chance to disparage this language and it's author". I stand by my refutation that these posts are appropriate, specific, relevant criticism, and that they cite specific evidence for their specific disagreements with the stated claims.

You are certainly welcome to disagree with this author's claims! That sounds like appropriate, specific, relevant criticism of this author's claim. Would you say that you are "frothing at the chance to disparage this author"? I don't.

I'll admit to some satire in my top comment on this subthread. By saying "It's because of all the lying", I was partly satirically reacting to what I saw as inappropriate hyperbole in "frothing at the mouth to disparage". I broadly agree that the V website is fine, just a little distasteful by my aesthetic.

If you think it's fine for V documentation and advocacy to overstate their case and not mention significant gaps in what they claim the language has, I can't see how you'd call it inappropriate for other people who care about the production-suitability of a language to explicitly document what they believe to be major gaps in the production-readiness of a language claiming to have important safety features people want to rely on.

For some context on my interpretation of these posts, I think about how many times over my career I've had to deal with software that claims to have "just a few bugs" on something important, but somehow the bugs never actually get fixed, and the fully general solution just never appears. These things really are genuinely difficult to design and build a fully general solution for. It takes time and engineering work, as we can see by these people finding a lot of holes as soon as they looked.

As an engineer, I've had a lot of frustration from dealing with bugs and outages and maintenance issues that can be significantly improved by a good language. That's why I care so much about really wanting these things that V claims to have, and also why I care so much about the details of how exactly the claims currently fall short. It's so easy to overpromise, so I'm skeptical of any marketing for a new still-in-development tool that just claims to have solutions, with no big disclaimers about how they're still incomplete.

Regarding your specific example, the problem that's being implied by the "setting array length on creation is a terrible idea" is that every time you're setting an array length in V, any mistake will not be caught by the compiler, and can be an exploitable memory safety violation. Memory safety vulnerabilities really truly have been and continue to be a serious ongoing source of serious computer security problems. V making various memory safety claims like no null and no reading from uninitialized memory, and then that being trivially broken on literally the most obvious possible violation, without even any safety marker to make sure it's obvious that this is a place where you can violate memory safety, means that it's just not a language I want to use.

I agree that these posts are very passionate. I assert that these posts come from a passionate interest in what V aspires to be, and they hold V to a high standard, and find it believable that V can actually hit that high standard, and so they've checked it, and here are the places where you'll need to be extremely careful if you want to really rely on this in a high-reliability setting. It is not frothing at the mouth, and it is not disparagement; it is accurate and precise and specific and appropriate feedback, along with some emotional expression that I find relatable and appropriate.

I was referring to both the original post, and Xe's older post that this comment thread is about. They both list claims made by V and describe details how they tested those claims and what their results were.

https://mawfig.github.io/2022/06/18/v-lang-in-2022.html https://xeiaso.net/blog/v-vaporware-2019-06-23

Hmm, interesting, I may have been misreading you.

I agree that 6-year-olds and other people without any production sysadmin or SRE experience are going to have a pretty bad time learning to build and deploy a Kubernetes cluster.

My point is that any professional sysadmin or SRE can learn Kubernetes just fine. Yeah, there's a lot of stuff, but there's just about as many moving parts as I expect for a system that handles what Kubernetes does. You also mostly don't have to pay complexity cost for many optional features you don't care about; you can get a minimal cluster up, and then grow it as you need more features.

I don't follow what you're saying about port 443. The kubelet API is not listening on port 443 by default. I'm as confident as I can be without checking that no kubernetes components listen on port 443 by default.

Speaking more broadly, I agree that someone with no SRE experience and no network security experience won't get much value from 30 seconds of nmap. What I was trying to say is that "accidentally exposed the kubelet API to the global internet" is something that I expect a competent sysadmin to be able to detect and notice with 30 seconds of nmap.

When I'm saying "deploying kubernetes is fine", I'm saying that anyone who has any business running nontrivial production services in a professional setting will not have any trouble learning to use and deploy Kubernetes. Deploying a cluster does require competence with sysadmin or SRE fundamentals, but not particularly more so than other systems that handle similarly-complex topics.

Also, any junior sysadmin or programmer should be able to learn to use an already-running kubernetes cluster to deploy basic services with no trouble and just a bit of time. I have trained quite a few people on this, and it really does go just fine.