skysight-inc/HackerNews huggingface dataset:
> Why would network programming (I/O, persistence, etc) look any different whether the language was C, Java, GoLang or other?

Because different languages provide different abstractive tooling and can thus yield different solutions?

> Plenty of noob code ignores errors. I sort of thought we all decided that was suboptimal. Java's response was checked exceptions.

And it was a bad one. Which is OK, everybody makes mistakes. That doesn't change the fact that Java's checked exceptions are bad.

> The only argument I've ever heard that made any sense is the silliness of catching exceptions so far removed from the root cause that your code can't do anything about it.

Made any sense with respect to what? Checked exceptions? They're bad because their classification is often incorrect (exceptions are checked which should not have been, mainly IOException) and Java provides no abstractive capabilities over them so you can't build tooling around them or intermediate layers which are not aware of the specific checked exceptions without losing that specificity (you can't be polymorphic over checked exception), they're either extremely leaky or completely erased, and things have gotten worse as Java integrated more functional features which have run head-first into these issues.

Plus they're inconvenient, because managing exceptions in Java is as verbose as everything else and by definition checked exceptions requires more management than unchecked.

> It now occurs to me that the checked exception abolitionists are advocating Happy Path Programming.

That's certainly not correct. Checked exceptions "abolitionists" just consider Java's checked exceptions to be bad.
One of the first widespread security vulnerabilities I had to deal with was this one:

https://www.giac.org/paper/gcih/115/iis-unicode-exploit/1011...

You could basically encode DOS commands in the URL bar for a site running IIS and it would run remotely.

The automated attack basically replaced the index.html pages. But if you didn’t use the default pages. It didn’t have any effect.
It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none.

Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value.

In reality an attacker is just going to dump strings and try them all or simply set a breakpoint just before the important syscall and let your program do the work. Code obfuscation provides little to no value for these common methods, yet we cannot resist the urge to list it as a bullet point in security meetings, leading to a false sense of security.
Thanks! That's helpful, but like you say it's also confusing.
You can always make a career in project management.
Article misuses/misunderstands the term "security by obscurity", and is attacking a strawman position based on its own definition of what it means.

Security by obscurity refers to a situation where security is dependent on the secrecy of an algorithm (the algorithm not being widely known or peer reviewed) rather than (or in addition to) a secret datum used with that algorithm.

The opposite practice is to use a well-known algorithm and depend only on the secrecy of the inputs to that algorithm.

The layers of security presented in the article do not meet the definition of "security by obscurity".

Even a port number like 64235 is a secret datum, not a secret algorithm. It's not a hard-to-discover secret datum; it is poorly guarded. But that's not what "security through obscurity" means. Using a funny port number is a widely-known system, with an objective benefit: it requires an attacker to take certain steps that are not required with a known port number. The assumption is that the attacker knows that alternative port numbers are being used.
shape of the code

This is an undervalued aspect of development. The tactile shape of a block of code conveys some aspects of intent, and overly aggressive linting tools destroy that intent.
Sorry for the vague wording. I meant "could" not as a statement of their actual ability, but as a hypothetical. If they did make such a car, Tesla would still sell better because of the brand. The current public narrative says that Tesla is cutting edge and futuristic, and Chevy is old school. Tesla's brand evokes images of cars as smart as their drivers, and Chevy evokes muscle cars and old pickup trucks. EV sales will reflect that regardless of how their cars actually compare to one another.
Sometimes the response you get from someone after telling them something and showing them something are different.

Those who already agree with the point probably think it long-winded. Those who would argue the point if told it probably appreciate the nuance the context provides.
It was debunked and reaffirmed within a narrower context and in general is a pretty controversial concept. Many people however have the personal experience of a limit to their willpower and that's what I'm referring to in the article. I'll actually edit it to remove the reference to Ego Depletion, thanks for poking me.
I feel like I could have written your post, even today when I am in a fairly senior position and paid an uncomfortable amount of money. My advice for when this feeling gets overwhelming is to just put your head down and get a bit better than you used to be.

I don't mean study really hard, just learn any small new thing and over time you'll improve.

There's no rush and it's ok to be average. The fact that you say the "alternatives seem dreadful" means you are probably in the right career!
What incentive is there?
The Hungry Ancestor Diet
April is usable within Common Lisp. When writing a CL program, you can invoke APL code on arrays. For example:

(april-c "{⍴∪,(3⍴2*8)⊥3 1 2⍉⍵}" (opticl:read-png-file "/path/to/image.png"))

This snippet uses the opticl library to load a PNG file, and then uses April to count the number of unique colors in the image. Consider the amount of code this would take in CL.
I agree with you. Fear of leaving your bed because of anxiety is not the same as fear of having a gun pointed to you. You can be happy to be able to overcome your small fears, but get out of your bed is not really bravery.
Have you tried JavaScript?

All kidding aside, it takes ten years to stop being awful. If you look at code you wrote a year ago and think it looks bad, that's a good sign. On the other hand, if you look at code you wrote a year ago and it seems about as reasonable as code you write today, maybe you're right. If you love tech, there's always devops, and if you're in the same boat there, you can try project management, or become an expert in some niche field. Or maybe tech's not for you. That's ok!
As I manager I hear this sort of thing regularly,

1. Imposter syndrome, a large portion of developers have it and this could be you. Chances are if you have a job and continue to ship code to prod you are at least partially suffering from imposter syndrome.

2. Overwhelmed by the wide variety of skills, being a software engineer in a professional environment requires way more than coding skills. You need to be adequate with GIT, Programming Languages, Unit Testing, Various Frameworks, CI, Deployments, Team Dynamics, and more. If you are only able to write code every day will feel like a big struggle to get anything done. Identifying which area is giving you the most trouble and doing focused learning will help you.

3. Lack of methodology in learning, a lot of people rely on their feelings to help decide what to do next. For some people that means learning a bit of this and a bit of that but never learning enough to be productive. Having a plan for what you need to learn and the order you want to learn it in can be tremendously helpful for growing your career.

4. Lack of methodology in coding, most coding jobs have similar steps when solving day to day problems. Making your self a checklist of steps can be very helpful for taking the stress and guesswork out of your day. For instance, step 1 pick up a ticket and understand the requirements. Step 2 pull from the git repo and run all tests. Step 3 Right down a development plan. Step 4 write code. step 5 write unit tests. step 6 submit a pull request. These steps will probably look different for each project and developer but help to ease the tension of figuring out what's next.

I'm sure there are more things specific to your situation but don't give up and keep working towards your goals.
I think we are similar in this aspect. I'm self taught as well, no CS knowledge to speak of from any formal training. The thing is, while most of my colleagues at work stopped caring about programming many years ago, I stayed with it.

The key to becoming a "good" programmer is basically just continuing to do it and to ask yourself "why did I design this like this" every now and then.

I've been at it for like ten years now, and every two or so years I'll have an "aha" moment where something clicks.
Sound like you "feel" like you're a bad programmer. What are some specific examples where it can objectively show you as being a bad programmer?

> I also suppose that I'm an ok "hacker" in that I can get very interested / fixated on certain problems, although my solution is more likely to be a complete mess.

In what way is this a bad thing, and how specifically are your solutions "a complete mess?"
Also if the security get much more complex it's not worth it.

If it's sheap (initial dev + maintenance + usability) then why not do it?
Standard maths notation is sight first and sight only.

If you want maths for the blind you need to convert to something like s-expressions, which emacspeak and read perfectly.
One thing which clearly is not objectively presented is the claim to have easily debunked Apple’s argument that Epic asked for a sweetheart deal.

Wherever you end up, it’s not ‘trivially debunked’ just because of a line in Epic’s letter, which can reasonably be suspected to have been placed there only to serve this argument, and not because it was sincere.

We have to contend with Epic’s insincerity and self interest at every level of this, even if we ultimately believe a world with more stores on iOS would be a good one, and that has to include not seeing anything they say as ‘trivial’ or reflective of anything other than a designed legal strategy, which clearly includes deception and intentional breach of contract.

Again - maybe these moves are necessary in some broader arc of history towards a more healthy software market, but Epic is clearly willing to use dishonest to get what they want, and therefore nothing about what they claim can be treated as trivially true or false.

As for the article, note that it doesn’t “trivially confirm” Apple’s claim that epic has created the damage for itself by not just reverting the deceptive update.

The article is an argument in favor of Epic’s position, not just a briefing or fact summary.
He uses chord typing using buttons built into the handles used to steer the bike. There's a claim that it's not that hard to learn.
Job ads like this aren't allowed on HN (see https://news.ycombinator.com/newsfaq.html), but you can post in the monthly Who Is Hiring threads.

They appear on the first weekday of each month and can be found at https://news.ycombinator.com/submitted?id=whoishiring afterward. You post your job as a comment in that thread. Please read the instructions at the top and take a look at some of the other posts to get an idea of the conventions. These threads become closed to new comments after two weeks.

One important point is that you have to personally be part of the hiring company in order to post. Third-party recruiters and job boards aren't allowed.
> temporarily sounding smart or experienced

This is real talent. Don't underestimate it. Others can code like a superhero, but sound like a meathead when you talk to them (me often).
Or maybe we can just stop these mental gymnastics and give the political caste what they deserve.
For me, the first step was to consciously select meaningful values. That helped me to know what I should do and what I should not do.

The second step was weekly self-assessments regarding how well my actions matched my values.

It didn't take long to meaningfully and permanently improve my unconscious behaviors.
Corporations aren't natural persons and have no ethics. They are abstract creations of law and the only legitimate expectations of corporations as corporations are their responses to structural incentives including enforced legal obligations.

We can talk about the ethics of the actions of corporate decision-makers, but only while keeping in mind that structural incentives mean that decision-makers who sacrifice the narrow interests of corporate investors for ethical reasons beyond the constraints forcibly externally imposed on corporations are likely to, over time, be replaced by those who do not.

If you want corporations to act consistently with some view of ethics, you aren't going to do it sustainably by moral persuasion directed at decision-makers, but only by shifting the structural incentives.
I think it's more natural to gradually implement components as Erlang NIFs in Rust via https://github.com/rusterlium/rustler.
> There's not a single language I'd consider myself good with, maybe one or two I can write and maybe one I'm ok with. I can read most code and I suppose consider myself well read when it comes to tech in general, in that I have very surface level familiarity with all sorts of things many most people have never heard of, although I must stress the "surface level" part

Out of curiosity, how many github issues did you create asking why thing_x wasn't implemented in Rust "for safety" ?
That's understandable because a forced sale would be seen as a major loss of face and national humiliation, and might put the government in a delicate position at home.

The current Chinese state (on both sides of the Taiwan strait) came to be as the result of, and reaction against, such past humiliations (e.g., but not only, Hongkong). The 20th century history of China has been a reaction and struggle against these aggressions. So there are probably some people who would rather scupper the company in the US rather than give in, would also allow the government to play on that foreign aggression aspect without appearing weak.
I wish other languages would adopt this too...
I've gone from IC to Manager and back a couple times. The first time was becoming "manager by default" in a growing startup. I then moved on to another startup as a tech lead, became "manager by default" again, and eventually VP of Engineering. That startup was acquired and the teams dispersed, and I eventually ended up back in an IC role (which, despite assurances from my boss, ended up being a demotion resulting in lower bonus and reduced stock awards).

I sucked it up and worked as an IC for while and realized that, after 20 years, I have little interest in writing code for a living any more. I truly enjoyed the strategic and personal growth aspects of managing, so I left that company and have only taken manager roles. I find managing to be much more stressful, but supporting my people through these trying teams has been a highlight of my career.
You’ll end up double wrapping your exceptions though so your stack traces get a bit uglier.

Better to check if it’s a runtime exception and throw it again without wrapping it. Only wrap if it’s not a runtime exception. Also you should check if the thread was interrupted and, if so, set the interrupt flag again.

The worst part of this is having that dance littered throughout all your code.
Goodbye Feature Policy and Hello Permissions Policy – Scott Helme
Wiring up dependencies via XML is indeed a bad idea for the reasons you specify. But if you're going to wire up dependencies in code, you don't need annotations. Java already has a method for declaring and providing dependencies for a class: writing and calling constructors, which is clearer and checked by the compiler.
> Imagine if software engineers were actual engineers instead of glorified script kiddies.

Maybe you shouldn't need to be an engineer to write a document with some formulas inside?
Study suggests animals think probabilistically to distinguish contexts
Entirely this. Don't demand a competent practitioner with the illusion of authority when you're hiring for a patsy to take the fall for failure to deliver due to politics.
I buy Pringles because they're in a tube.

Ever take a bag of chips on a backpacking trip?
See the tips at https://news.ycombinator.com/item?id=22336638.
Yeah I don’t know, Portugal was a dictatorship until the coup in 1974 which ended the Estado Novo regime and the colonial wars Portugal was waging in Africa, ffs you had European powers conducting outright massacres in Africa in the 70’s still.

And somehow today its feels that everyone thinking that the European Union was formed on Tuesday following the pyramids and its been the bastion of human rights and civilization since.
> This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time).

Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For example, using base 64 encoding instead of encrypting something. Or running a code obfuscator on source code instead of making the code actually secure.

Either way the economic costs that I'm talking about are valid. If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port.

There are slightly different usages of the same word, but the effect looks to me to be the same. More investigation or automation can make the obscurity go away, but it does make things a bit harder.
I used to think I was good at calculating math but very bad at proving theorems because only geniuses prove theorems but us ordinary people just compute reliably. I couldn't make any headway at proving a theorem.

Then one teacher gave me an assignment and I looked at it and could not make headway. Then he told me: take your time. This should take you 2 hours or so.

That single instruction changed everything. I just stared at it and worked on it and stared at it and 30 minutes later I had figured it out.

Then the professor approached me to let me know that I should maybe consider go into theoretical comp sci as my major.

I have met math geniuses and I am not in their ranks. As Bezos once said in an interview, their brains are different.

However, it is worth pointing out: just give it more time. You don't have to see progress right away. If you set up a website or are doing some data science, you should expect little issues that will eat your time. This may be as trivial as simple as your python library is 2.7 vs 3.x or you have to load in C++ compilers and the error message is obscure etc.

The worst part is this drudge work is front loaded: before you start your app you have to pay these dues. Then once it is up and running you can experiment and you find a lot of progress being made.

This simple truism hurts newbies who don't see progress right away.
But it’s easier to find Arab women. Or an Irish girlfriend of an Arab man. Or two old Korean people.

(All real examples)
It's not because of experimentation–it's because Apple for the most part lets their team's choose what they feel is best for what they are trying to accomplish. It is trust. If there was a concern about a technology choice, it was discussed and pros/cons weighed, but there wasn't some standardization of language under the guise of "developer productivity".
I remember that year. I was giving a talk at EF during the same time slot but the schedule originally had me in the large room and they had a much smaller one.

When the news of the acquisition hit, everyone wanted to see the WhatsApp talk. The organizers knew this so we swapped rooms. So, I started my talk by asking if anyone in the room was here for the WhatsApp talk and told them they could quietly leave and I wouldn't mind and a bunch of people got up.

Heheh. I don't blame them. I didn't really like my talk and Rick Reed is very good at what he does and the talk is no exception.
Using obfuscation is often a signal that you are a weak target, because there are a lot of places that use obfuscation but nothing else. A better indicator that you are a hard target is to enable common mitigations like NX, stack cookies, or ASLR.
i think it's less pragmatic and more "nice". such as telling people they can be anything they want to be even if they are 5'2 and want to be in the NBA
TBH, I am mixing an album this weekend in a pair of HD280s, but a) I have been using this pair of headphones (well, everything but the drivers have been replaced at least once) for almost 15 years and b) I have mixed quite a few albums.

And I wouldn't choose to do that if I weren't stuck in an apartment or had the budget to rent a studio for a couple of days.

Echo and stereo bleed create frequency, amplitude, and phase cues that are important to listening, and while the room reflections or speaker deficiencies can cause a whole lot of problems, most folks are probably better off mixing on a home stereo if they had the choice.
Learn Python from the NSA [pdf]
There are things that could (should?) be done from the start. Most has to do with automation. For example automated build tools. Maybe you don't want automated unit tests in the beginning but those parts can be added later without changing the company's culture and stucture too much.

Or automated invoices. It is much easier to change this than changing a co-worker who manually created all the invoices.
Do you have a Bible? https://biblehub.com/sermons/auth/greenwood/spiritual_blindn...
Let me give you an example. At a previous job as a devops, of my predecessors frequently used these "techniques, minus the encrypted database but I sure he would have done it if he knew how. So there was some buggy internal app they needed some new features added to and the person who wrote it thought he was clever and obfuscated the code. It took me a whopping 30 minutes churn through his 'clever' obfuscation scheme and the randomized variable were just a nuisance. Honestly his best obfuscation technique was his horrible code that made no sense.

Even OP's advice about running services on non-standard ports isn't sound. Who doesn't run a service scan? Even sites like Shodan do service discovery for you. I'm going to find whatever port your running ssh on if your running it.
Well, yes. But where would the attacker be if they are in a position to intercept the traffic?

The answer to that may dictate if the technique would have value for you.
I can't say how LLVM does it but in a compiler I built I detected tail recursion by scanning the IR and if the value of a recursive call (ie: call to self) was immediately returned it was considered a candidate for TCE. If the value was consumed by the parent, it wasn't.