skysight-inc/HackerNews huggingface dataset:
Well, what's wrong with namespacing, exactly? Github, java, etc, show us that namespaces are perfectly fine. Not perfect, but fine.

The rest of Rust is extremely pleasant to work with; a lot of thought has been put into ergonomics and I love it as a result.

But with crates.io it feels like the opposite. I have to deal with name-squatting and a much more difficult naming process for crates as pretty much every short, meaningful name in English is taken at this point. For what gains? Less forks, less fracturing -in theory-?

I feel like a lot of the arguments for no namespaces are strawmans or make big stretches. For example, figuring out which fork of a project to use is really not a problem. And a lack of namespaces does not fix that anyways, because it's not a code problem... Importing two crates with the same name would be fairly rare, and rust easily solves that with `use crate::... as ...`. Etc.

Anyway, this discussion has been trod to death. There's no point having it, as I'll just be told why I'm wrong and why namespaces are just -impossible-.
That’s a ridiculously myopic response. Most of the world doesn’t have adequate access to sufficient education, clean water, basic disease prevention, birth control, etc. But here you are acting self-righteous about online app-based banking and comparing the lack of convenient apps with poverty induced food theft? You need a reality check.
Other people have replied, but if you really want to understand why they are right I cannot recomend Monty Montgomery's explanation/videos enough.

Unfortunately they seem to be down at the moment, but wayback machine to the rescue:

https://web.archive.org/web/20200202124704/https://people.xi...
> The developers have convinced themselves that they're right on this, having, I suppose, not learned from the hundreds of package managers that have come before them. They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change.

Comments like this are why this discussion has devolved over the years. It's "all heat and no light." It does not help convince anyone that you're right, and if you want this to change, I would suggest that you change your approach.

The team has stated that they are open to implementing namespaces, but that the people who advocate for them need to address the concerns. This hasn't been done successfully yet, and is part of what this post is trying to help out with, by cataloging some of the large amounts of previous discussion.
I agree there are some hints of bias, but I wouldn't think it's a biased piece.

You don't think Apple's arguments are objectively presented?
Just checked. Works for me (post author here).
How does crates.io treat bad faith stuff? Like if someone were to make com-steveklabnik-blog.
Imposer syndrome alert.
First, wait till tomorrow, see if you feel the same way. From experience, you're probably just in a mood bad because of some difficult task.
If you still feel the same way tomorrow, then my advice will be to just take a more deliberate approach to learning. Nobody holds on to details like "very basic OOP concepts" all the time. If you're in a funk because of an interview screw up, get over it. Interviewing is a job in itself. Take time to prepare (3 months at least) and see if you still feel the same way.
He's biking so the reaction tolerances are much looser more so if he's following back roads with very few cars which is sounds like he was from the another post where he talks about atlases.
Seconded on the imposter syndrome point. I definitely have days in my life when my internal narrative sounds just like your post, but if I take a step back I'm much further along than at those low points.

Another issue is that it's entirely possible that your current role doesn't challenge you to learn or retain CS concepts nor deeper aspects of the practical tools you use. Many jobs can be done very well using the same shallow toolkit repeatedly. If that's the case, it's not really a question of your ability, but maybe you can start actively looking for projects to force yourself to start learning more.
Find one thing, one small dimension, that really interests you and do a deep dive. Let your interest become a thirst, completely master that.

From there everything else will naturally happen. The problem most people have in situations like this is too much shallow knowledge, which doesn’t lead to real stimulation of curiosity and creativity. Find something that fascinates you and go for that.

Alternately audit the MIT CS106b course for free online and see if the intro to CS stimulates you intellectually.

Second alternately change careers to something where you deal primarily with people (like sales or product) or where you spend time outside.
If coding isn't your strong suit but you're still passionate and knowledgeable about tech, maybe tech-evangelism or a PM role would appeal to you?
It sounds like you enjoy programming, and have managed to get a job doing it professionally. Maybe just try to enjoy it? You might not be the world's best programmer but why does that matter?
Oh, this post hits home. Me too.
* Erlang builds reliability into the language and runtime through concepts of liking, supervision, …

* Erlang is a much simpler language

* Despite lacking a static type system, Erlang's functional bend, immutability, SSA and pattern matching makes for a rather safe language

* Erlang has always been fully preempted, it didn't have to wait until 2020 for that to happen

* Erlang also builds distribution in, though it's "trusted distribution" so probably of fairly limited use at large

* Erlang uses shared-nothing concurrency, greatly limiting side-effects across processes, which again helps with reliability: there is no action at a distance in sequential erlang, no third-party can come in and mess with your state

* when dealing with binary data, binary patterns are absolutely amazing (and rather unique)
Sounds like you need a good dose of stoicism: Don't worry so much about how good you are or if you can get better. Just focus on what you can control, practice your programming and focus on areas which you enjoy. You'll get better with time.
Ask HN: How to make home network secured
How can I make my home network more secured and block adtrackers and few websites and social media apps for the kids.
What services I can use
Wow so many points to address.

First up, you wrote quite a bit but never expressed something super important - do you enjoy developing, do you feel happy doing it? Or is it just a job and a means to put food on the table?

Secondly, technology is a broad area and I actually knew plenty of developers who quit within 6 months and went into other tech areas (sales, project management, etc.).

Finally, I've been coding for decades and sometimes I feel crap about my own work too when I look at the quality of stuff that some others are able to produce. I'm at peace with that though, because I know my real skills lie elsewhere. That, and I'm happy doing what I do, I feel good about it and I figure if I keep trying I can only get better.
This is an interesting instance of two HN tropes in conflict: Managers are able to ‘create’ more (by improving IC productivity) than any individual contributor (and thus more value), unless you believe in 10x engineers.
I don't know Debian's specific history, but having participated in volunteer organizations, getting everyone to agree on how to spend money can be tricky.

Personally I'd love to be making more open source contributions as well, and I've been thinking off and on about taking a sabbatical to make time for it, though that probably won't happen.

I might be able to help find dev work for you that doesn't involve technical interviews, though it may not necessarily be a "job".
Security by Obscurity is great. This is a takeaway from the port knocking conversation here last week. If there's a zero day exploit in sshd, I'd rather it be behind some layer you would have to "know" to get in, rather than sitting open to the world. Why make your target bigger than it needs to be?
One thing I didn't see discussed in the article was the balance between the benefits of security by obscurity, and the benefits of having your code open source (or at least making your security methods known) so more people can audit it. Personally I don't actually think there is that much security benefit to having open source code since most people don't audit random codebases for fun, but that is one of the arguments I've heard against obscurity. Of course some methods of obscurity can still be done with open source code as well.
Yes, there was an ongoing criticism from Joel regarding storing plain text passwords.
Depends. You bought your groceries there? You paid their price.

You offered extra money to the grocer to sell to you something that was already sold to someone else that had already paid? I would count that as a bribe, and yes, it is a corrupt thing to do.

Epic is literally paying people to go back on their word, or in some jurisdictions, literally commit a crime by not delivering on purpose something that was paid for, in some places that is called interference, in others it is called fraud.
I regularly use git add -p. Also git rebase -i.

I get the feeling that people don't really know about the interactive git commands.

TBQH most people don't explore git beyond the pull-add-commit-push flow, the ones that do immediately feel like they need a GUI where a TUI would do just as well.

Oh, talking about TUI, I also use https://jonas.github.io/tig/ sometimes.
Ask HN: How are wildfires propagating when hotspots are far apart from ech othr?
The wildfires seem to be miles away and isolated from each other, so how are they propagating?
Controlling hardware: C.
Here's one for ya. Legacy third/fourth level domains on ".ca". They were provincial/municipal respectively. Although new issuance was discontinued in 2010, they still exist.

For example, posts from ansuz.sooke.bc.ca have been popular on HN. Sooke is a municipality, BC is a province.

https://en.wikipedia.org/wiki/.ca#Third-level_(provincial)_a...
Anduril's New Drone Offers to Inject More AI into Warfare
Or even just watch some of the foundational class lectures available online for free.

If you haven't been through CS in school, watching MIT's CS50 classes will introduce you to a lot of basic concepts and language that you'll find helpful.
Check this hard against all our tendency to have "imposter syndrome". I've suffered from it in the past, and eventually I found my groove. Now I lead teams.

That said, you could also pursue engineering adjacent paths. Things like project/product management, QA engineering, sales engineering, etc.
Thank you for replying. It helps me to better articulate my thinking. You're my Rubber Duck.

Why would network programming (I/O, persistence, etc) look any different whether the language was C, Java, GoLang or other?

Most of my code is error checking and handling. (And now logging too, which I'll ignore here.) Is this abnormal? (Being rhetorical.)

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

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.

So don't do that.

Really, why would any one design a system that way? Because network programming is messy? Because it'd be neat to compartmentalize the messiness?

I've been able to cleanly separate the value add business logic from real world messiness exactly one time. I was in control of the full stack, end to end. Imagine something like a useful BizTalk. I had been inspired by postfix. My engine would pass work to plugins, which didn't have to do any I/O of their own. My work anticipated serverless and AWS Lambda, if those programming frameworks (paradigms) were better designed.

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

The only other feasible Happy Path Programming strategy I know of is Erlang. I've only done an Erlang tutorial, nothing in prod, so this is just a guess.
there is a tool for rectangular waveguides as well.

http://www.wikarekare.org/Antenna/Waveguide.html

one of the things you get with these antenna styles would be lobing. there is usually four side lobes, at quarter wave peaks a diminished rear lobe and the front lobe business end. wifi dongles with removable antennas are not so common nowadays but you can install an SMA connector if you have steady hands and a fine solder iron, just remove one from an old router.

there is also the usage of the whole router with custom firmware configured as a repeater or an extender with custom antennae

yes things are made hard ...for most people but thats when the hat goes on head and hard == fun, challenging

and yes you want to mind the power you put into these things and what you point it at. my first cantenna also had a rifle scope, webcam, and a laser pointer in a tidy little gang. i never got around to stacking it on a PTZ camera but theres still time for fun in my schedule

[edit adm] The connectors are not so problematic if you have stuff sitting around you and are not shy of modifying the feed connection, i run sma coax soldered to the routers board on one end and 50 0hm connection on the other end. the connector is only convenience any way you can solder the coax end in place at the waveguide and you will actually get rid of signal loss due to the connector impedance. it also helps to keep the coax length short but avoid multiples of the signal wavelength or you will get reflection in the wire.
One of the bigger problems is that exceptions are slow. Thus the recommendation is not to use them in cases where the caller could branch on. A perfect example is a missing element in a remote system. An old api would throw some sort of a Element Not Found Exception. With the addition of Optional though you have a object that is easier to use, conveys your intention better, and doesn't have any of the performance drawbacks. I think what it comes down to is that when dealing with situations that might be handled by the caller you should use some sort of result object instead of a exception. This leaves exceptions only for the cases where the result cant be handled. In which case you dont need checked exceptions.
I think you've realized you're not a Rockstar or 10X, not that you're terrible. Most people aren't Rockstars or 10X, and some question if those even exist.

Your best bet is to try to specialize in the tech within your professional space. If you're working for a company, work hard to understand the technology and codebase they are using. Try to learn best practices, and see how you can integrate them into the existing codebases. You'll maybe learn the patterns you feel you're lacking, and also learn that a lot of times stuff is not coded with best practices in mind. There is tons of production code hacked together and barely working, and in a lot of cases that doesn't matter, it only matters that it's technically working.

Management may be an option for you down the line if you're feeling you're still not confident coding is the right thing for you. I am sure people would love to have a manager that is at least relatively competent at reading code and tech literate.
> I assume whenever you grew distant from some friends, you had other friends who you weren't distant from - it was staggered.

true-ish when I was a kid. although for most of my childhood I didn't have any friends anyway, either because I didn't "fit in" or because I'm just not a very gregarious person. since the age of eighteen, I've had the step-wise N to zero several times: once when I graduated highschool and went to college out of state, again when I transferred schools, and most recently when I graduated college and got a job. I'm not saying it doesn't suck, just that it's not particularly unusual, at least for adults. having only lived one path, I can't really say whether it's better to be exposed to this reality early, or to be mostly sheltered from it until after highschool.
I just want to throw a plug for the concept of Railway Oriented Programming. It can be laid on top of almost any functional-ish language that can implement some sort of Result(Ok,Err) return type. And to the OP's point, you can catch exceptions where they occur and `return Result(Err(details))`.

We applied ROP with great success at a fintech where we wanted to clean up a block of business logic with many failure paths. Instead of a forest of nested conditionals or try/catch mess, there was a very simple happy path with clear handling for all the errors.

Here's a good start. Ignore the language details, the concept is universal. https://fsharpforfunandprofit.com/rop/
Arguably, most security is security through obscurity.

No password -> simple password -> complex password

Plaintext -> Caesar cypher -> Vernier cypher -> modern cyphers

40-bit crypto -> 56-bit crypto -> 128-bit crypto -> 256-bit crypto

0.0.0.0 network allow-list -> /24 network allow-list -> /32 (per host) network allow-list

allow by default -> deny by default

standard port -> non-standard port

We just add layers of obscurity until they add up to "enough" and don't grow into "beyond tedious".
Hmm... didn't take all that much effort:
https://electrek.co/2020/06/25/rivian-r1t-electric-pickup-st...
> This is a matter of philosophy of course, but more objectively, there are many many people actively regretting their choices.

I think this is a part of the power of the quote. It essentially says, don't judge your decisions with hindsight. And remember that having made the other choice could equally well have turned out bad as far as you knew back then.
It’s a great problem to have. I’d love to have that problem. Give me that problem. You choose how much to purchase and wait for the wealth to materialize.

I’m sure most people would love to have this kind of problem. Gimme. Gimme.
Well, if you're not very good, or feel like you're not very good, get better.

How to get better?

Evaluate your strengths and weaknesses (ask a friend/manager who's willing to give critical advice).

Plan and practice, practice, practice.

It's a mental game, too. I find the sheer volume of knowledge out there to be overwhelming -- don't worry about this. Start where you are, and add, incrementally. Nobody goes from A to Z.

You got this. Ping me further if you want a mentor or accountability partner.
Does anyone do the pendulum? How well does it work?
Have you looked into being a QA / Tester?
Good ones are hard to find but you don’t need to be a great programmer even though you should absolutely try to automate most tasks thrown your way.
Man, that c++ code triggers my hatred of lambdas. Instead of a hopefully descriptive function name, whose code I can peruse separately from trying to understand the enclosing code, I have to understand every goddamn line in real time.

lambda more than 5 lines should be a compile error.

Why not move C++ towards readability instead of enabling laziness in the guise of features ?
> "Don't do security by obscurity!" But then we all implement passwords (which is just security by obscurity)

Thank you for being someone else who recognizes this. If having a secret piece of knowledge grants you access to the system then it's obscurity. Once we admit that then we can start talking about the difficulty of guessing that knowledge as the actual important factor.
It's all about what you WANT to do. Most of us developers who have been in the game a long time have times where we have periods of doubt. Only you can know whether your doubts are real or not.

If you don't want to develop software there are many ways to use that experience. You could move into QA. If you can write, you could do technical documentation. If you can organize things well, maybe technical project management is up your alley.

There's lots of options, if you think about what your strengths are. You can use your development knowledge to make your other strengths into a great job. Or stick with development. Most of us aren't ____________ (insert rockstar developer you've read about in a blog, here).
Money though right? You might do well as a test engineer
It's not really a direct security advantage, so this is mostly off-topic, but changing the default port does greatly reduce log noise, and theoretically could be a bit less taxing for your network connection or CPU if it's a cheap server not intended for publicly hosting services. (If it is then the traffic would be a drop in the bucket compared to regular production traffic, though. And it's admittedly probably a drop in the bucket either way.)

Reducing log clutter alone probably does confer some small indirect benefit, since it's less likely a more sophisticated attempt or successful breach would go unnoticed when inspecting logs. (Assuming there's some SIEM log forwarding or that it's not a situation where an attacker was able to or wise enough to wipe logs.)
Buy and read the books "Cracking the Coding Interview" and "Domain Driven Design". You'll feel better.
I also don't like gatekeepers. But it just seems it always evolves to that.

My point was not that I don't mind gatekeepers, but more that if you get rid of the platform gatekeeper, you will end up with the "customers" gatekeeper. In the end for us developers or customers it makes no difference.

$300 should not be a problem for someone who sells proper software. Such $100+ gates keep a lot of the crap out.
> The claim was never that using obscurity is bad and should be avoided.

Yet. All of these are from HN.

> 3. Since when is obscurity a valid security measure?

> Security through obscurity, not a valid security plan.

> The problem with these "obscurity as a valid security layer" arguments is that there's already obscurity built into these protocols.

> Especially since most people believe "Obscurity" to still be a valid security technique.

> You're just reciting the same tired old rhetoric that security through obscurity is a valid defense mechanism. It's just not.

> I thought the general consensus here is that security by obscurity is bad.

> Obscurity is bad because it makes you _think_ it adds security.

> To maybe give some perspective _why_ security people say that security by obscurity is bad - and especially serving ssh via port 64323: [...]

> I dismissed it as security through (bad) obscurity but is there a valid security reason to do this?

> Compression is not encryption and security by obscurity is bad practice.

> it's understood that security by obscurity is bad.

> Security by obscurity is bad, of course, but in that model it's such a minor factor.

And countless many more. Some of these reference "security by obscurity", which, if you're kind, you can interpret as "security only through obscurity" (though reading in context this mostly doesn't seem to be what is meant), while others dismiss obscurity entirely. You will also regularly find commenters lament this point of view as the "mainstream idiocy".
> But then we all implement passwords (which is just security by obscurity)

No it isn't. Security by obscurity is explicitly keeping things other than passwords and keys secret.
One advantage of putting ssh on a non-standard port is that your logs, which are otherwise filled with automated ssh break-in attempts, now become almost empty. It's much easier to look for other problems when the signal to noise is increased.
> The work done by a database engineer is different from the work done by a VP marketing, or a director of database engineering. It is not inherently better or worse, easier or harder, more or less deserving of praise and admiration. It is simply different.

The big problem is that it is the VPs and directors who are getting together and deciding what everyone should be paid. And, lo and behold, somehow, they almost always decide that VPs and directors should get paid more than database engineers.