Rust was beta for many years and started becoming mainstream only 2-5 years ago. Go was in production almost its entire existence, it's specifically a simplified language.
The labor theory of value has nothing to do with collecting profits and isn't concerned with who gets it. It argues that the economic value of a good or service is determined by the total amount of "socially necessary labor" required to produce it. (https://en.wikipedia.org/wiki/Labor_theory_of_value)
My point is that value is actually not determined by "socially necessary labor" but by supply and demand, even within a commune. The food you produce will rot if you and others produce too much of it = it has no value, and nobody collects profit (not even in the form of social capital) because everybody lost any possibility of selling for a good price by producing too much.
On the other hand during a shortage people will start valuing food much more than they previously did, gradually paying higher price as they have less of it - again totally disconnected from the "socially necessary labor" required to produce it.
Most importantly - the value of most if not all things is subjective and different based on time, place, etc. Even within a commune - some people simply don't like peppers, so even though you put a lot of work into them they have no value to these people (which will quickly change once there's a food shortage).
It's never true. It's like a broken clock - it's right 2 times a day. When the conditions are exactly correct, it seems like the labor theory of value is true - but it's not. Consider a simple example - food production. Nothing changes about the labor necessary to produce it but that doesn't mean you won't have to sell your produce way under price (or let it rot) if you and other farmers make too much of it.
Ah, okay, that makes more sense. Sorry I misunderstood. This is not really something applicable to my line of work (standard software development tasks on a larger project in an agile team managed by the client) but I can imagine some of my friends doing this.
Clients find me, not the other way around. Documentation and implementation are my own lines of work.
I have an accountant, tax advisor and lawyer as subscriptions. I also have a coworking pass. These cost me about 1.5% of my annual income.
Trainings are given for free in coops? I can't imagine myself or my friends working for free, are you forced to work for free in a coop? As in, would I be forced to give trainings too? I value my time too much for this. Of course I do the occasional free tech talk for my friends/the public, but that's not in any way comparable to a "full" training.
> If you are paying someone to do any of these jobs, you are doing it out of income that you've paid taxes on.
No. As a contractor, all of the above are my business expenses (also including conference passes, trainings/certifications, driving to/from the client, all my hardware I use to work etc). Companies and contractors pay tax on profit, not turnover.
> Also, some cooperative companies will only outsource work to other cooperative groups.
Yeah indeed there's a coop like that where I live. They pay like half of what I make to their top guys (I myself am not a top guy; they offered me even less). Not encouraging.
> Not to mention the camaraderie of working with people with similar goals in a noncompetitive environment where they value your success.
I have this at the coworking space - and we don't share any money so there's no chance of any bad feelings whatsoever. I have very bad experience with that, it ends friendships.
I don't understand... I work as a software contractor in EU. I don't see a single thing I'm missing by not being in a coop. 5% of my income is a lot of money. For that money I can buy all the accounting and tax advisory services I need with enough money left over to get a Wework All Access membership and even then I'd have a significant portion of the 5% left. Why does it make total sense that people are interested?
> Because different programs, implemented differently, run at different speeds...
We're talking about two programs with exactly the same purpose - ingest TypeScript and output JavaScript. It's a pretty clear-cut comparison, IMHO.
> The Go code, on the other hand, is usually simpler and quicker to write
I'm writing Go code at work, and Rust code mostly for fun (but used it at work too). I'd say this has changed significantly in the last 2 years. Now with rust-analyzer and much improved compiler output, writing Rust is very simple and quick too. I guess getting into Rust can be a little harder if you've only ever used GCed languages before, but it's not that hard to learn - and once you do it's super-effective. And the type inference of Rust is a huge reason why I'm using it - while Go has none.
Another thing to consider - usually the code in Go is much more about writing algorithms yourself instead of using library functionality (this is changing slowly thanks to the new support of generics but most code hasn't caught up yet and there aren't good libs using it so far). The resulting code in Go can be convoluted a lot and contain very hidden bugs. People also usually don't bother implementing a proper search/sorting algorithm for the sake of simplicity/speed of development - which you'd get automatically if you used a library function - so the code is less efficient. My Go code is usually 2-3x longer than the equivalent in TypeScript or Rust.
Go is great, I like it. Rust is great too. I recommend you to do what the esbuild author did - test it and choose for yourself, don't bother too much about others' opinion.
So you're saying they wrote exactly the same program in Go and Rust for the comparison, changing the syntax only? Well then it's no surprise the Go version was faster.
Don't write Rust as if it was Go. That doesn't say anything meaningful about either Go or Rust.
If they paid 5x the normal price of toilet paper and they were picking it up in the middle of a desert then yes I'd assume there's something shady going on.
> A real world example is esbuild, the author implemented it both Rust and Go initially. The Go version was faster and the code simpler. Which is why it's implemented in Go.
But why is swc faster than esbuild then? The code isn't even considerably more complex.
> the law authorizes the President of the United States to use "all means necessary and appropriate to bring about the release of any U.S. or allied personnel being detained or imprisoned by, on behalf of, or at the request of the International Criminal Court"
It might not be expressly stated, but it's pretty clear. Sure, it's a super-extreme case - but it's there, explicitly saying "by all means necessary ...".
> They'll only let him come to the US if the U.S. guarantees he'll go back to the Bahamas for their charges.
The US has a law that says they will invade The Hague if the court there makes a decision they don't like. Are you sure there's such thing as "the US guarantees"?
Financial advisor without professional insurance? Why would anyone do that? Shouldn't they be the people who know how to use financial products and services to protect themselves?