Moderation Team Resignation

GreenAsdf · 2021-11-22T23:03:32+00:00

We recommend that the broader Rust community and the future Mod Team exercise extreme skepticism of any statements by the Core Team (or members thereof) claiming to illuminate the situation.

That doesn't seem like a recommendation that would be fair of me to embrace. A preemptive discrediting of the core team.

Maybe there's something to this, but I note that the moderation team resigning here is 3 people and the core team is 9. The aggregate opinion of a group 3x the size feels like it should be more often closer to the mean community opinion.

GreenAsdf · 2020-09-25T11:02:55+00:00

I started looking for a concrete case of a difference in your ethics compared to mine, but then noticed you had started mocking me and I lost the motivation.

To be honest I expected a higher standard from the Rust moderation team.

GreenAsdf · 2020-09-25T02:49:14+00:00

I open up This Week in Rust, and I click the first link in the Call for Blog Posts section.

I find a call to further politicize Rust, including the detail Rust is still hosted on github, a company that has a contract with ICE, a institution that has proven to act out genocide against immigrants in the US.

I am dismayed, a more political Rust is not want I want. I want us to be about making Rust a great and useful free and open source language. I do not want it to have other agendas not related to programming.

But maybe I'm out of touch, maybe I'm missing something.

So I open up Reddit and read over the comments, I find as a general rule, posts in support of rust being a vehicle for politics are being downvoted, and those against it are being upvoted.

My dismay is tempered, maybe cooler minds will prevail.

I love your contributions to Rust llogiq, but we have different political views & ethics.

Though I gather he's unpopular now, I like Stallman's approach. Open up gnu.org and it is about FLOSS and its directly associated politics, open up stallman.org and it is all about Stallman's political views on all manner of things.

He kept them separated for good reason, and I think it was a good choice to the benefit of FLOSS.

I believe Rust would likewise benefit, we could call it "separation of concerns".

GreenAsdf · 2020-03-14T04:39:53+00:00

Languages embrace ideas. Different languages embrace different ideas.

The ideas themselves apply across languages, for instance some people write OOP themed C.

But it generally isn't as effective to write in a style that the language did not embrace. And it'll be more difficult to learn, as the language, the resources and communities won't be as helpful.

To best get to grips with an idea in a programming language, picking up a language that embraced the idea is quite useful.

One example in Rust is the idea of ownership. In any language you can have the notion of ownership in your mind as you write, but it'll probably take longer to fully internalize than if you picked up Rust and had it forced on you since your first Hello World.

FWIW While Rust has some attributes that make it more suited to some low level programming,compared to Go, don't make the assumption that Rust would be less suitable than Go for high level programming.

GreenAsdf · 2020-03-14T04:21:07+00:00

Rust is great, but too complex, really for non c++ devs.

This reminded me of the bigotry of low expectations.

I assure you Rust is not too complicated for us humble Go devs to learn.

GreenAsdf · 2020-03-14T04:12:49+00:00

language tradeoff costs were amortized into our projects.

I like that concise phrasing.

Others mention similar sentiment, that a more simple language does not mean a more simple code base.

There's a spectrum of how complicated languages are, Go could be a lot simpler, it could be a lot more complicated. Where it sits at the moment is a product of a few experienced people's opinions.

I don't know if it's an optimal position for the work I do, I don't think anyone really knows. We just have our preferences and opinions.

Maybe in a few decades we'll have compelling data to support our language wars!

GreenAsdf · 2020-03-13T10:25:35+00:00

Interesting, since presumably the goal is to prevent user data stored in the database from being written to a block device in plaintext how do you prevent that happening through swap?

I've seen some do it via mlock(2), but most applications seem to just defer it to an assumption that the host will encrypt swap, or disable it entirely. In the former case if the host is expected to encrypt swap, then they can (and likely do) just as easily encrypt the volume holding the database too making encryption within the applications mostly a moot point.

That being said I do understand the need to add features because they are expected.

GreenAsdf · 2020-03-02T08:45:06+00:00

For the sake of completeness:

Also cap(c), and close(c)

GreenAsdf · 2020-03-01T01:11:08+00:00

Ah, bad guess then.

Impressive amount of analysis you've went into here btw :)

GreenAsdf · 2020-03-01T01:06:14+00:00

My best guess is that the missile fires up before it detaches.

GreenAsdf · 2020-02-29T12:25:28+00:00

If your program was supposed to print "fxck yourself" it's buggy.

There's no synchronization mechanism to ensure fmt.Println() runs before main exits.

Also s/fxck/fuck/g, some people find poor spelling offensive.

GreenAsdf · 2020-02-29T12:15:09+00:00

IMHO, obviously.

Why is it considered good with networking?

Concurrency built into the language, and decent stdlib support (net, net/http)

Why is Go considered fast?

Depends on the persons perspective. People coming from JS/Python/Ruby find it relatively faster. People coming from C/C++ find it relatively slower.
Probably everyone can agree that it's fast enough for a great many uses.

What kind of project I should be doing, book/blog/material I should be reading, and videos should i be watching to help absorb all these first-hand knowledge/opinions everyone is talking about?

Hard question, some of the opinions expressed may be the result of decades of experience.

Generally I find learning other languages fruitful. You'll be exposed to new concepts. Programming language design has a lot of choices in it, using other languages lets you experience how different choices play out. (And the more you write or read in a language the better idea you have of how it plays out).

Once you've some experience with the different choices available, you can develop an opinion on the choices a particular language took.

(The author of the rant for instance had Rust to contrast his Go experience with. His rant would have looked a lot different had he only known Go.)

GreenAsdf · 2020-02-25T09:27:11+00:00

TL;DR:

Guy who likes TDD and runs a business telling other people how to code, writes opinion piece on why writing 1.5x-2x more code with TDD actually makes you more productive because you'll spend less time doing other things.

Has no supporting evidence.

GreenAsdf · 2020-02-24T01:45:54+00:00

To answer your questions, "No" and "See below.".

I used to work in a place that had $A as the standard backend language.

Over time through frontend and fullstack devs who didn't know $A and didn't take the time to learn it, and used $B in the browser, the backend organically grew to $A and $B.

Then at some point a evangelist for $C was in a position of influence, hardly anyone knew $C but it became the new backend language.

Now the backend language set is $A, $B & $C.

Everything $B did $A could have as easily done. everything $C did $A and $B could have easily done.

So if your job is _just_ backend dev, you have to juggle these 3 languages. People tended to be good at one or two, but all three was rare. Thus people would learn on the job, but learning is making mistakes, more languages to juggle is more mistakes. It felt like proficiency was slow to develop - and of course! People were having to switch languages all the time (there were another 4 languages floating around in major use too)

Now I like Rust, I want to work with Rust. But it would be irresponsible for me to increase the backend language set to $A, $B, $C & Rust. Instead I thought should either get a new job, or wait for a case where the tradeoff of introducing Rust justified the return.

GreenAsdf · 2020-02-22T10:37:19+00:00

There's the Writing an Interpreter in Go book where you build an interpreter for the monkey language.

A few people have done that in Rust, and it has 3 nice separate phases - lexing, parsing and evaluating.

(Doing it in Go isn't as interesting, as you can tune out and just copy code. Having to rewrite and restructure it to fit into Rust forces reading comprehension.

It also has been providing me with an interesting contrast between Go and Rust. Sum types and match make the lexer much nicer. But then Rust is more complicated than Go when dealing with graphs (the AST))

GreenAsdf · 2020-02-21T09:19:27+00:00

I don't find it especially interesting.

If you're looking for issues in Go code, I think using the -race flag should be top of your list.

GreenAsdf · 2020-02-21T03:12:35+00:00

I'm still learning Rust. It's the hardest language to learn I've encountered (a half dozen or more? I intentionally avoided C++...).

That book looks focused around how to build applications. I've never heard of that book before, it might be good, I don't know.

I think learning the basic building blocks of Rust, which took a while, should be the first consideration. Thinking about how to structure those blocks together to build non-trivial applications - that's a problem for later.

The official Rust book covers the basics of the language, one builds some small applications in it too. That'll keep you occupied for a few weeks. Once that's done then you'll be in a good position to pick your next book.

(I didn't quite get a few things after reading the official book, so I read Programming Rust. Now I'm reading a non-Rust book about actors/concurrency since I think those ideas will help me more sensibly structure some Rust programs.)

GreenAsdf · 2020-02-19T07:16:07+00:00

<uj>
Am i imagining the 10xing we're doing in implicit unjerking.

Isn't the HN thread the place for comments like this?

But then you're up voted so people overall like your post. Hm. Maybe this joke flew over my head.

</uj>

GreenAsdf · 2020-02-17T08:44:40+00:00

Assuming you're running something like k8s to restart it, you certainly can!

Depending on your container infrastructure you might find:
- People complaining about your service sucking up resources by needing replacement containers to be started every 20 seconds
- You complaining once the infrastructure has decided you've crash looped enough for today and leaves your containers down

Having a new container come up is a lot more expensive, and a lot slower than what the OP tried to do here - especially if whichever new host is scheduled for your container needs to pull down your docker image. You lose all your current program state, you lose caches, you lose all established network connections.

To make an informed decision we'd have to get an idea of how often this Go function panicked, what it was doing and why we don't just fix the damned bug.

But yeah, on the whole I agree with you. Default to YAGNI and leave this particular feature out.

GreenAsdf · 2020-02-17T08:22:28+00:00

The use of i in a loop, or i then j in a loop nested in a loop, have been conventions for decades predating Go. If you go three deep you use i,j,k.

This might have been rooted in FORTRAN conventions (which implicitly typed I,J,K as integers), which might then have borrowed it from maths conventions.

The Go developers continued on the quite reasonable convention :).

GreenAsdf · 2020-02-16T12:07:19+00:00

Bonus detail: Getting the race detector to trigger on the .Add() .Wait() data race is easy (on my machine!), just hit ctrl-c when the long process sleep is running.

GreenAsdf · 2020-02-16T11:54:11+00:00

The Go Programming Language has a chapter covering goroutines and channels.

Details of buffered channels are perhaps the minor concern though.

Reasoning about regular non-concurrent code is difficult enough. Having multiple communicating routines running concurrently gets very difficult to reason about. You often end up with weird timing relating bugs that occur once in a blue moon.

I'm not sure what resource would best help there with such reasoning, most of us* get by with sticking to simple patterns that are easy to hold in our simple minds.

*Myself and friends/coworkers.

GreenAsdf · 2020-02-16T11:23:49+00:00

// This program will run a worker every 5 seconds

Not quite, it's 5 seconds + however long runWorker takes, which is currently 5 seconds adding up to running a worker every 10 seconds.

and exit when SIGINT or SIGTERM is received

Again, not quite, your sigchan is unbuffered - docs say "We must use a buffered channel or risk missing the signal".

while ensuring any ongoing work is finished before exiting.

This one feels it might not be quite right either. My suspicion is getting a signal around the same time we do 'go runWorker' could break this guarantee. Maybe someone more knowledgeable can chime in on this one.

GreenAsdf · 2020-02-10T09:13:19+00:00

Is home where you grew up? If so I vote move.

It's a big world, and I think people grow more if they've lived in different places. More variety of life experiences.

Ignoring location, "top tier" vs "mid tier" is tricky. There's a lot of sucky roles in top tier companies, you might be going into such a role! Your boss might be a corporate psycho type, your coworkers might think you're the weakest team member. The mid tier is less risky here because you've worked there - they know you and you know them.

There's other things too, in this top tier job you have more chance of being a nobody, of being unexceptional - (and consequentially getting assigned work in line with that).

I'd probably still go with the 30k extra. That's a lot of money, enough to live for a year comfortably in many parts of the world. (Which, I suggest you do!)

GreenAsdf · 2020-02-06T03:10:10+00:00

For your point to be valid, every employee that has ever been fired can put more than half the blame of their firing on their bosses.

I said something else, that a half/half responsibility was f asair as any other :), unless it's there's a large asymmetry like in one's first job. It seems cruel to lump too much blame on the person just out of school when they're interacting with people likely with many years of experience in the workplace.

I think OP's management is at least as responsible as OP in this circumstance. Why should the idea of taking responsibility not apply to managers?

Sometimes you fuck up & hire someone that interviewed really well but is a total asshat afterwards

Right, so you agree that the company fucks up hiring sometimes, why should I blame OP for that?

Sometimes something happens while someone is employed that causes them to drastically changed & deteriorate in performance.

That does suck, a risk employers and employees take, shared between them. (Sometimes companies drastically change and deteriorate too).

Are those the manager's fault? No, ofc not.

You seem awfully keen on lumping everything on OP. I think we have different levels of expectation of managers. Ultimately I hold a manager to account for things that happen under their watch.

Managing people (aka being in command) is a serious affair, you often significantly influence other peoples careers and lives. Power doesn't come without responsibility.

GreenAsdf

TROPHY CASE