chessturk

I upvoted you and the gp, but I also would like to point out that the useful answer often still arrives before the pendatic closure.

Some of my own questions followed that route, without being dupe questions and while being a code-based success or fail state. The closure of tickets is detrimental to the site, but somehow, it's still worth asking a question.

It's arguable that domestic violence is less cold and more passionate than the characteristics you're describing. I understand there are cold sadists, but speaking to the archetype.

Additionally, in the case of a bigot, the outcomes involving subjects of prejudice may be less meaningful to them even at a subconscious level. Coldness and bigotry can coexist, and certainly produce emergent results.

Also, that the best outcome of using surgeon who has a history of domestic violence is that they're so disassociated from the world, that beating a loved one doesn't matter is a really strange argument. Perhaps the argument is there isn't a better way, but damn.

I used to not be sure about robot surgeons, now I'm pretty convinced.

If they beat women, they may not value them as people?

I agree. I've sincerely asked for explanations what is missing when pattern matching is so similar to type inference. Combined with guard clauses and "let it fail" philosophy, what is the problem other than boilerplate? Is it lack of mechanical refactoring? Totally honest question for type enthusiasts, my other posts have been met with silence.

Have they considered rewriting it in Rust?

That is what I meant, don't know why I put product. Too many meetings.

Do you have an article on this? I didn't know that was possible.

How does this relate to Go? That flew over my head.

My job has internal tool that reads MySQL schemas and outputs a CRUD golang api and json-based form uis to interact with them.

I think it could be it's own product, but leadership doesn't care.

The nation who allows future North Korean dictators to be educated at their schools? I doubt it.

> I'm convinced the only possible savior at this point would be a Superpower aggressively enforcing environmental regulations to the point of going to war over it, but that seems unlikely.

It could feasibly handled economically. I've wondered if a stronger world govt a century or so down the line saying eco friendly or tariffs. I can't speak to liklihood, but it seems feasible.

I'm not buying a lot of this "motif" usage stuff, but if you want to speak entirely speculatively, I'll bite.

Marxism extensively argues that it is easiest to oppress people when you categorize them differently. An example would be how poor whites weakened the rights of free slaves in post Civil War America. Marx would argue the rich propagated racist beliefs to the poor whites who then limited the rights of other poor people. The end result is the poor limit their own democratic representation. Scientific Socialism is an essay by Engles (coauthor of the Commumist Manifesto) where he argues all oppression is based off of sexism (infantilization, dehumanization, objectification) and shows how the concepts of oppression are modified for race and class, so each group appears different but are actually the same. How this would apply to advertisers might be to preserve the status quo, or to make people feel bad to compulsively buy.

Not saying I agree with every aspect of those arguments, but it is a well documented attempt at answering your question.

> Then came a long awkward phase where I tried to fit in closely with other people's styles and figure out their intent and design - this is a very difficult way to write code and I wasn't very productive.

My first gig was at a 3 person team, including me. The other two wrote their code in basically identical format. I ended up codifying a linter config to make a style guide that basically all existing code already fit into. I remember thinking, this is never going to be so easy again.

Your post makes me think I was right.

I knew a shop that refused to move its customer data out of an ancient MS Access instance until one day it just started shedding records.

That's what I think of when I hear technical debt.

What are examples that make sense and don't just explode in your face?

This realization is what has attracted me to the Erlang/Elixir world where fault tolerance > provable correctness.

The end user would rather have an application be frantically logging errors in the background, but be working for their usecase, than a program that is fixated with being correct and refusing to run in the presence of errors.

Obviously quality code still matters, but at least in the business realm "does it do what I expect?" is basically your success/fail state.

The problem is private banks, state run banks can pull all sorts of crazy tricks. Look up how the Bank of France lends the country of France money, which makes them much more self sufficient than the US and its sale of bonds instead. No matter what anyone tells you, the fed is not a central bank. It is much less powerful and cannot protect the economy as well as a true one.

I'm pretty sure something like phone banks (in or out-bound) are filled with low-skill workers whose credentials would be valuable to data thieves.

I've worked low wage jobs for the Government and Private Industry where we were hit with ransomware and phishing attacks. I think you are underestimating how many workers are really in that position. I'm not sure if you're American, but it's very common in America.

Many people don't get a bonus. If you have no benefits, an hourly wage, and no path for advancement, the only thing they can do is whine or fire you.

The first point is definitely a positive point for typing.

The second I feel is by design. A runtime exception is better than undefined behavior, which was the other option when many of these more abstract languages started taking hold. We're just reaching a point where languages with undefined behavior are being competed against by projects like Rust which offer similar performance without the same risks. Runtime exceptions become less attractive when you can avoid them and avoid undefined behavior with more comprehensive solutions.

That line sent a chill down my spine. I'd hate to refactor those devs' work. Oh wait, that's my day job.

Can you give me an example of this? I'm genuinely wondering if I've just dodged a pain point so far.

My other strongest languages are Golang and JavaScript, so I'm used to (duck-)typed and untyped approaches, and I've never felt that Elixir was difficult to work with because of the lack of types. I've treated pattern-matching like type inference, and as long as you have guard clauses, the worst that can happen is a runtime error which you "let fail" anyway.

I guess the guard clauses are a bit of boilerplate, but I feel like these complaints have a different root. I just don't see it yet.

I find them completely equivocal. This is the geeky version of the orange/white dress.

My boss says that's the world we're about to repeat.

I kept a real nasty implementation of this alive for the last two years while building a REST api and React frontend to replace it.

I learned a good lesson, though: no logic in template files! Ever!

It's all relative. Plenty people come from Node, Ruby, and Python.

Coming from the Go! world, I view Elixir is trade of speed for OTP out the box niceness. But comparing Elixir to Node, then you're just gaining speed and stability.

And it keeps going -- I very frequently see Go criticized for slowness by C, C++, and Rust developers. It is all about the usecase, which is why I find this topic so interesting. It's one of the few situations Elixir mid-level speed is actually a real world problem.

Though I bet I largely share your feelings, I feel like there is an interesting converse in terms of distant history looking back.

Things like HP Lovecraft renouncing racism is only preserved because he wrote so many damn letters. It doesn't make the racist stuff he wrote less racist, but it allows a really clear view on how worldviews could change at the time. Perhaps the things we are storing will have historic or philosophical value.

I miss real privacy though.

A friend of mine was getting a real estate license and talked to me about the insane ways land ownership is measured, because the curvature of the earth. I believe that was just the tip of the iceburg. I'll have to check out geodesy.

I remember an ancient mathmatician described how all of existence must be a single geometric point, I think it was Euclid, but I can't find it. This all reminds me of that.

The philosophy of Go, as far as I can tell, is opinionated simplicity. In this way, it is fantastic at concurrency.

It gives you a simplified fork in goroutines, a way to safely pass by value or signal between these through channels, and structures like select to psuedo randomly deal with race conditions.

That stuff is all awesome!

But when you are talking about performance, opinionated simplicity is a bad philosophy. You are going to want the finer grained control the poster is asking for, and which Go deliberately doesn't allow for. C, C++, and Rust will always have a speed advantage because they lack the overhead of the GC and were designed with allowing the developer minute control of the system, which is the space to make such optimizations.

That said, opininated simplicity means every Go codebase I drop into looks roughly the same. That is not true in the above langauges, precisely because they allow for more control.

To me, Go's ideal use case is the domains of Java, Python, NodeJS, and even Elixir -- where it has a performance edge in many cases and where its consistant style really shine.

All that to say, Go is bad at performance optimized concurrency, as designed.

My experience has been channels are a really good way to make highly concurrent code readable for people who hate concurrency (ymmv).

They aren't as efficient, but using them as a semaphore (i.e. only signaling) can facilitate fairly-efficient, easier-to-read shared memory. But I'm kind of proving the whole...

> You can very carefully design around it only channels

...part of your post.

As a fellow gopher, I agree, Go isn't trying to compete with C/C++ on performance, it's trying to give you safety and ease of use of high level language.

I think the point about concurrency typifies this, channels aren't as fast as mutexs and semaphores, but it makes sharing code with co workers easier to reason about.

If you're in a domain where performance is still king, Go isn't trying to find a place there.