Coding is the tip of the 'working in software' iceberg. If you don't see value in being able to communicate the reasons behind the technical choices and trade-offs you've made, both within your own team and to other stakeholders then you'll quickly find that your coding time is quickly eaten up by people asking you to explain it.
If you value periods of deep focus or 'flow' then believe me, having concise, accurate documentation that explains why, how and what you are building pays off - if only to help you separate the planning from execution process in your own workflow. I don't think any moderately complex software can be written without some degree of planning - but maybe your experience differs
My house is in a mobile phone blackspot - no reception on any network. I tell every guest if they want to receive or make calls they have to join my wifi and enable wifi calling.
> It is difficult for governments to commit large scale atrocities without the consent of the governed unless those so governed are first disarmed.
Not when the government has tanks, attack helicopters and assorted hardware that IS prohibited for the public to own
> A more modern example was the prohibition of the free movement of the Australian population during covid. Australians were held prisoner by the state and were not permitted to leave.
Not true. You could leave and you could also enter - but would have to stay in mandatory quarantine.
I hate that argument about how gun owners would not pose a credible threat to the US military.
We've demonstrated time and time again what a determined populace in their home region is capable of doing to a technologically and numerically superior opponent.
Such as in Vietnam which isn't incredibly dissimilar from the deep South, or Afghanistan which is very similar to the environment you would find in Idaho and Wyoming.
I mean the wider discussion can still be had but if the federal government decided to start a fight over this it would be very similar to an Afghanistan or Vietnam situation but about 2-3x worse as the area to cover would be much larger and would likely have to deal with internal problems in the military as they tend to be very well represented in the pro-gun crowd.
Unless your suggesting the US military would start carrying out strategic bombing operations against its own citizens on its own soil.
Fine, it's the threat of your guns that is doing such a grand job of keeping you all so very free.
Almost 1% of US citizens are in prison. Your police forces routinely brutalise and oppress large parts of your population even though (or perhaps because) you are all armed to the teeth. The majority of your fellow citizens are a couple of paychecks or one health scare away from homelessness, your social security safety nets are in tatters and your collective Labour rights have been eroded away over the last 50 years. Thank goodness you've got your guns or your government might screw you over
Gun rights have been systematically (illegally) denied the demographics that comprise the majority of those so imprisoned, which furthers the argument that large cross-sections of the population being armed reduces violence.
> Your police forces routinely brutalise and oppress large parts of your population even though (or perhaps because) you are all armed to the teeth.
Those are the groups frequently denied weapons. The police generally actively avoid armed confrontation with those they know to be armed (such as we recently saw in Texas). This is one of the reasons it's so easy for them to shoot and kill (mostly unarmed) minorities.
"An Australian citizen or permanent resident (the person) must not leave Australian territory as a passenger on an outgoing aircraft or vessel on or after the time this instrument commences"
100% agree. Just want to point out that you can integrate API Gateway with DynamoDB directly (with some Velocity mapping). In fact here's a blog post from 2016 showing just that - the use case being a comments API: https://aws.amazon.com/blogs/compute/using-amazon-api-gatewa...
This guy (https://www.youtube.com/watch?v=tMLu9Dtw9yI) makes some good points about how cheap and scalable the technology is for medium-scale energy storage. It uses tried and tested, reliable and simple components for example
Back in 2001 I worked for a 'Medical Communications' company, building marketing websites for various drugs companies. I was young, it was my first coding job and I desperately needed the money
I even ended up building an internal marketing website for use by sales reps pushing an antidepressant. It was an awful PoS, technically, but it had a basic CMS system and I was flown to the US (from the UK) to show the very friendly team at the drug company how to use it. I was fairly blasé about the ethics of it - they paid a lot of money after all. The drug in question was later removed from the market after it was found to increase suicide risk.
14 years later, my mother had maxxed out on the same kind of anti-depressant. She kept relapsing and the doctors kept upping the dose until they couldn't prescribe her any more. She took her own life shortly after.
Not so long ago, I interviewed a candidate for a data engineer position at the 'FinTech' I was lead engineer at. He turned us down because he didn't like the CTOs attitude towards the credit data we were collecting about our customers. Until that point I hadn't really considered the ethics of what we were doing, again. I started looking for another job the same day.
I know it's been mentioned before, but I really feel there is a need to codify an 'internet lore law' about how many comments can appear on a Go themed HN post before someone brings up how superior Rust is
Something like:
Pikes law of unfavourable comparison
OR
HN Golang oxidation rate
I suspect that, programming in Rust is so onerous, that Rust programmers must take lots of breaks and troll Go threads so they feel less bad about themselves.
Or maybe they're just waiting for something to compile?
To be fair, I remember thinking the same thing when Go was new. HN was pretty dominated by everyone apparently switching to Go (if you were to believe the general attitude anyway) and how Go was the clear path in the future
Not that it is or isn’t and clearly Go does things really well in some problem spaces but yeah, this seems to be a common theme for all young languages
I do think some members of the Rust community Take it waaay too personally, which I never saw in general when Go was the hip thing. That I agree can be very obnoxious
Well it's pretty relevant when considering a new feature for a language to consider prior art is similar languages (the key similarity in this case being the compilation model), no?
Your comment itself should be codified. Maybe it’s just another growing language with a large community that itself is dedicated to improving the language. Rust is newish, and changing rapidly so it’s a good candidate for comparisons between modern languages. It helps that it’s designed completely in the open so the sauce can be seen.
Not to pick on you or even the other child comments but the amount of people that complain about a language being compared to a modern equivalent is funny. What about every other thread on HN where the same thing happens? It’s alll turtles just enjoy the discussion
Nah, there's something unique about Rust zealots in this respect.
nicoburns comment is completely off topic, and it's extremely obnoxious to see this kind of thing over and over again from the Rust community. And I even like the language!
The Rust promotion has unfortunately changed lately. I've noticed too that they not only tell everyone how great Rust is (which is fine) but started bashing other languages (which is sad and not doing any good for the public image of Rust).
Rust is from enthusiasts for enthusiasts. If the Rust community wants it to become more real / main stream, they need to look at how the Go team focuses on supporting devs for getting things done correctly with long term stability.
If you prefer I can provide examples on how Windows, macOS/iOS, Android resources work for their native language SDKs, or how Java and .NET embedded resources work.
The Rust community does have an uptight attitude, as if Rust's success or lack thereof is a matter of life and death. This can be seen in general with languages which haven't achieved wide-spread success yet.
If you value periods of deep focus or 'flow' then believe me, having concise, accurate documentation that explains why, how and what you are building pays off - if only to help you separate the planning from execution process in your own workflow. I don't think any moderately complex software can be written without some degree of planning - but maybe your experience differs