davidjfelix

They're a mistake because correcting the language level issue with trailing commas to fix diffs was the correct solution. Instead everyone had to convince themselves that they prefer leading commas, which is not how commas are used, over whitespace. Have you ever considered maybe your coworkers are right?

I did prefix my opinion with "IMHO". But no. Leading commas are, in my opinion, less common in life and a distracting, surprising style for the sake of fixing a syntactic language mistake. "Enforce" might have been an overly demanding word. Enforcing when there's a newline is probably more apt or simply allowing it to prevent giving leading comma folks ammunition.

something like `[hello, world]` should probably be allowed since `[hello, world,]` feels extraneous.

IMHO prefix commas is fixing one mistake with another mistake. Enforce trailing commas.

Sounds like you might love doing meaningful work.

No problem. I'm by no means an expert, just a sufferer of burnout myself and a friend to a few people I've seen struggle with it.

I think sometimes the unfortunate news you'll learn is that you did something during your career path that felt right, but put you in the wrong situation down the road. The type of change that's needed to correct that might be learning something new, applying to jobs you'll love more that are perceived as "beneath your ability" or simply changing trajectory.

Burnout is kinda like an injury, it makes new injuries more likely and you need to train around it.

I think there are a few things that I've found that always help:

* Removing the source of frustration or the thing that is burning you out -- this might mean quitting a toxic job, reducing hours, whatever. But be honest with yourself, ask for somebody who you talk to a lot to give input on what they think it is and listen.

* Rest. This doesn't have to mean "do nothing" but it can. I think a lot of people do nothing for not enough time. A 2 week vacation and then back to the grind, you may find yourself feeling fresh and re-burnt out in less time than you were gone. I'd say rest more accurately means "do something that is easy but keeps you active" or "do things you've neglected, but don't push the area you're frustrated". I find that working on something that's lower stakes or requires less back and forth and allows me to think through and fix without questions of my dedication or intention are most helpful for me, but for you it might be something else. If burnout is around coding, managing a complex, non coding problem might be helpful. I have friends who have done home improvements or setup beer brewing etc to focus their skills on somewhere lower stakes.

* Do recovery "exercises". If big projects or coding has burnt you out, slowly introduce it in a healthy manner, accounting for the changes you made by removing frustration. This should feel like the most difficult part, because you're attempting to do something new. Introduce the thing you want to do but you've been prevented because of burn-out and try slowly to do it while addressing any strains the source of your injury immediately. This might mean having more candid discussions with managers or team members to prevent toxic patterns from emerging. This may mean tempering expectations early or setting clearer boundaries. Do the hard thing and prevent re-injury. Taper, and don't increase capacity until you're sure you're gaining energy rather than losing it again.

* Be patient. I've been burnt out pretty badly with projects and it's taken several months of healthy, quiet coding in the back seat of a good team to feel well rested again. It's given me a lot of time to assess what went wrong, what I liked and what I have missed about my time resting. I'd say probably 6mo for just a single terrible 2 months of work. Be patient and trust the process.

Honestly, I write pulumi in typescript for a lot of the things I used to use terraform for. I don't think it's perfect -- the goal of a "pulumi program" (what they call it) is to generate a dependency graph that is then executed by the engine. The output dependency graph is basically what I used to write in terraform, but not in HCL. I think that having access to a full programming language is less bad than people assume it will be if you just give access to a standard library that provides resources they might write poorly (pulumi used open source terraform providers to bootstrap their codebase). With typescript, I get access to modules, familiar testing libraries, normal module loaders, normal dependency upgrade notices, etc. The downside is I'm tied to the declarative configuration engine (in this case pulumi). If we so chose, we could write modules in multiple languages and coexist the codebases in an org (right now pulumi supports python, go, c# and type/javascript)

I think you accurately picked out a problem with using purely declarative data languages -- many of them adopt or bolt on rudimentary templating languages that are inferior, bespoke and often just as turing-complete as a normal language and they're terrible. HCL managed to go pretty far with just "count" but now in HCL2 they have looping structures.

So: what is ideal? I think there are several declarative functional languages which are starting to look really good for the space, albeit a bit early -- Cue, Dhall and nix. I think all of them come with their own baggage which is why it's probably good they weren't used, but I think the point is effort could have been made to adopt them rather than dump an untyped blob structure on users.

There are a few issues I take with YAML as the de-facto language used:

* It's dangerous for capturing types it supports accurately without devolving to JSON+, especially for a "human focused" data language. It's very easy to get into undefined or mal-defined areas that are trying to be syntactic sugar.

* It presents no concept of schema or type safety to its users without being hoisted into a tool, which means all validations are implementation specific, if they exist.

* It's incredibly verbose for duplicated items, which makes it really prone to typos and hard to spot mistakes.

I think strong gitops operators are already using tooling to generate yaml for them so it's basically an intermediate representation anyways. Languages like cue and dhall embed a concept of schema validation, but if we want to use our own external tools to generate it, why don't we just say "you know what, if you want to manually write it, it's JSON, and here's a schema you can validate against" but if you want to use tools to generate it - every major language has a *correct* JSON parser and there's already a well established schema specification for generating types, with libraries available.

I think the mistake was encouraging people to write the intermediate representation manually and then letting them find a way to bolt real language features on top.

Hey now, don't blame this on front end -- this is gitops with k8s kustomize.

Really bummed that YAML managed to sink its teeth into the IaC community as badly as it has. I know we have a hard time agreeing on programming language preferences in general, but this has to be the worst case of fallacy of moderation that we're experiencing in modern times. Like -- this simple interaction is spread across 5 files with no explicit import system?

I really don't think it's that simple. Ethics bend and break around inconvenience.

It depends a lot on the state that one resides (or incorporates) in. With LLCs they mostly all follow the same pattern and if you're the sole owner they can be done without charter, initial incorporation docs, etc. With coops, some states follow uniform common law LCA (limited cooperative association) laws and allow worker-owned coops pretty easily (although lawyers are generally less familiar as they're rarer). Other states only allow certain kinds of coops and require charters and organizational documents. Basically, any time you involve more than one person, there is some paperwork (LLC or otherwise). Coops have this, plus the added difficulty of not being uniform around the US.

Last I looked, Colorado and IL had a lot of coop options to choose from, but nothing was as straight forward as an LLC where you just file 1 notice with the state and pay 100 bucks. LCA states are close, but you still have the "many people" issue.

I think the issue isn't citing it directly, it's citing it incorrectly. Wikipedia is a snapshot collective understanding of a topic, hopefully in a meaningfully cited manner. It's not that it contains false information or unreviewed information, it's that you're attempting to cite a discussion and collective work that is constantly in flux. I think that if you were inclined to actually do investigative work, you'd find yourself:

* Interviewing "experts" (their level of expertise would be something you'd need to establish since no third party has prescribed that) who contribute and discuss the topic.

* Referencing cited sources.

* Referencing edit history and reverted changes, rejected sources, etc.

I think the issue is that academia has a lot of systems in place (I'd argue that they're only partially effective) that help establish credibility of experts and sources through "academic honesty" policies.

IMO, part of figuring out how to properly cite wikipedia will come with a reckoning that academic honesty isn't 100% nor are the arguments of authority that come from academia quite enough to establish credibility. I think that's the real issue -- this shorthand is pretty good, but it doesn't mesh with wikipedia's own shorthand.

Realistically, no. Credibility is often a crapshoot which I think is why you see so many otherwise-intelligent individuals believing nonsense.

This is the kind of FACT based analysis I look for when complaining about computers on a computer forum. Could you possibly assign a "truth score" to this for me so that I can ask a scholarly journal (which has never been accused of publishing falsified data) to publish it!?

Sorry for the sarcasm. I've been rolling my eyes at the comments too. Where do these lunatics come from?

My guess is if you saw an outage with edge, it was because you were being routed by us-west-2

Yeah, you can select "edge" for some resources (API Gateway and Lambda are two that come to mind) which just means it's located in all regions plus some additional "edge" infrastructure that isn't available as a region. AWS puts some restrictions on edge resources since there isn't enough capacity or full-region functionality.

Usually you pick this for stuff that is CDN oriented and front a regional service with that.

Total tangent, but gRPC is not dominant and I think that belief is cargo-cultism.

Ease up, I'm quite sure it was a joke.

FYI to author (who is in the comments): you may want to prevent the graphs from allowing scroll to zoom, I was scrolling on the page and the graphs were zooming in and out.

This only really tracks if they intentionally wear socks on specific feet. While some socks have L/R indicators, most don't.

Which language is the one where you make sweeping generalizations?

What's wrong with svelte's documentation or the community interaction that's happening around svelete?

My point is that you've seemingly taken points away from Rich for the same reasons you're giving Evan You validity.

Migrating between react and vue would take probably the same amount of time -- I'm not really sure what your point is here. My point is that you've unfairly discounted Svelte on the same standards you're raising vue.

That's kinda moving the goalposts. I agree that Solid is one of the more viable competitors to react for the combination of JSX + a VDOM-less model (this operates much like svelte), but my point was that it wasn't *Solely* Solid's use of JSX (there are many others adopting or trying to adopt JSX) that makes it viable.

I agree - I think JSX does what templating languages have been trying to do for years.

That being said, solid is hardly the only one out there competing that can use JSX:

- https://github.com/vuejs/babel-plugin-jsx

- https://mithril.js.org/jsx.html

- https://preactjs.com/guide/v10/getting-started#setting-up-js...

I think people are starting to see the power of it when it's used in a functional manner (rather than early class-based components). A lot of alternate template libraries are only minorly different in syntax and use different styles of interop to handle the crossover. I think .svelte and .riot are fairly close, while still being somewhat html-like, rather than JS first.

Re: Sapper -> Sveltekit, you might say the same thing for React Router users who adopted Reach-router, back to react-router and are now on remix-router or next.js router.

Also I found it weird that you mention Evan You WRT vite as a counter to why Rich might be up against stronger devs, but Rich made rollup, which was foundational to Vite's bundling.

The problem I see a lot in people who have a hard time debugging is continuing to assume all of their base assumptions in the face of a bug. You've hit the bug because of assumptions, so ask yourself: which one of those assumptions, when changed or challenged could produce the outcome you're observing? Sometimes those assumptions are as basic as "I typed everything correctly" but other times they're more nuanced like "I assumed this library only throws when getting a transport error not an HTTP error code". IMO, it's a muscle you exercise. You build understanding in your problem space and get more skilled at identifying likely culprits for bugs. Early on though? It's a lot of asking, seeking and brute forcing.

Also, print statements or use a debugger to confirm assumptions. (I'll be honest, I rarely bring out a debugger unless a print based workflow is time consuming enough to justify remembering everything about the debugger).

That's a LWW (last write wins) resolution strategy. Here's a pretty good overview of a variety of CRDT methods: https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

So there are two possibilities:

- There is no reason to take them and this process will slowly fail over time as companies who adopt these policies slowly push away talent options.

- You are not the target audience of a take home assignment hiring process.

I think it's easy to believe the first since it affirms your world view. Speaking as somebody who has a deep pocket of job opportunities and has taken one of these take home assignments, sometimes those opportunities become stale or you're in a tough market or need a job immediately. A number of companies who have bad hiring practices are still fairly acceptable to work at, even if it's not ideal.

TLDR - to pay the bills.

I mean -- that's the reason I switched to asdf, but my point is mostly that languages are building these tools into them so there's no split ecosystem, it doesn't require shell hacks and has much better ux than if it were provided externally like asdf is. I appreciate asdf for unifying all the shell hacks but rustup works way better than any other tool. As languages start to do this, asdf starts to become a mono-tasker for node for me.

I've been using asdf for awhile because it's was good and much easier than having a language version manager for every language I was using. Asdf was always pretty good, but I'd sometimes see slowness and starship (my prompt) would occasionally complain that the shims were taking too long.

As languages that I'm using are starting to adopt their own version manager (rust/go), I'm left using asdf pretty much exclusively for node and my eyes wander to some of the node-only tools like volta and fnm which use rust and I wondered if people were watching performance. Glad somebody is.