snowe

so it sounds like default frontend, maybe tied to the version we have (we're still a few versions behind), only mobile ff.

My response would be something along the lines of “Do you use a different phone number or email address depending on the topic of the conversation?”, but the blank stares quickly remind me that I am part of the last generation that actually talked on their phones and wrote emails to actual people.

I mean... not a phone number, because that's not given out willy nilly, but emails? hell yeah. I don't use my work email for private convos, just like I don't use my junk email for coordinating group trips.

But just like you choose an email to converse with (do you have gmail? well that says something about you. Hotmail? same thing), you only communicate on the fediverse with that account. it doesn't mean your identity is that topic. It just means its your home base. Just like gmail or hotmail might be your 'home base'.

Most of us will however be better served by joining a a neutral federation or - even better - by running the instance under your own domain.

which is choosing a topic (yourself) as the root of your identity. Maintaining your own instance is hard. Maintaining a large instance even harder. Growing that instance and keeping it from turning into Reddit (isn't that why we're all here) means making choices about what you want to be. Programming.dev was never meant to be a catch-all. I was the main moderator of /r/ExperiencedDevs and frequently helped people on /r/cscareerquestions. I wanted a place to replace that, but that still had other things connected to it. A sort of in-between between HN and Reddit.

At the very beginning of the exodus, there were instances popping up left and right that had absolutely no connection to each other besides all saying "lemmy". We had lemmy.net, lemmy.world, lemmy.news whatever. Tying your identity to lemmy (or the fediverse even) is a losing proposition. The website should be able to grow no matter what tech it uses, and no matter if it's federated with this fediverse or not.

The choice in making a topic-ed instance was a deliberate one and a very thoughtful one. You can't grow if people have no clue what you are or what you do. Reddit took literally 14 years before it was mainstream enough for people to start coming over from facebook groups. Whether that's something to be desired or not, you can argue about, but it is a point to make that when you tell someone "Oh I use reddit" they're like "what's a reddit". That doesn't happen with programming.dev. And it doesn't happen with other topic instances like solarpunk or mtgzone or literature.cafe. You know what you're getting when you go in (a programming forum), and you happen to be able to use that to communicate with other forums rather than having the diaspora that is Discourse or BB, which you can joyfully find out after joining. Needing to know that something is the fediverse before going in is terrible for discovery and honestly terrible as a website idea. Reddit grew because it happened to be a forum of forums which many people wanted. But a forum of forums where you can choose literally hundreds of sites (and you have no way of knowing which are good or even mediocre) or even host your own? That's too much for most people, even software devs.

https://programming.dev/comment/10856293

It seems that something went wrong with our nameserver, thus no connections to the 'outside world' were working. As soon as I added a new nameserver, federation started working again (this also affected server updates).

I do not. I'm sorry.

https://github.com/nektos/act

Does type inference provide a practical benefit to you beyond saving you some keystrokes?

it's more readable! like, that's literally the whole point. It's more readable and you don't have to care about a type unless you want or need to.

What tools do you use for code review? Do you do them in GitHub/gitlab/Bitbucket or are you pulling every code review directly into your IDE? How frequently do you do code reviews?

I use GitHub and Intellij. I do code reviews daily, I'm one of two staff software engineers on my team. I rarely ever need to know the type, and if I do Github is perfect for 90% of use cases, and for the other 10% I literally click the PR button in intellij and open up the pull request that way. It's dead simple.

My response to the article is that you're sacrificing gains in language because some people use outdated tools. Code has more context than what is just written. Many times you can't see things in the code unless you dig in, for example responses from a database or key value store, or literally any external api. Type inference in languages that have bad IDE support leads to a bad experience, hence the author's views on ocaml. But in a language like Kotlin it's absolutely wonderful. If needed you can provide context, but otherwise the types are always there, you can view them easily if you're using a decent IDE, and type inference makes the code much more readable in the long run. I would say that a majority of the time, you do not care about the types in any application. You care about the data flow, so having a type system that protects you from mismatched types is much more important that requiring types to be specified.

it does if the other ones have edible seeds, seeds without arsenic, or fewer seeds... your analogy makes no sense.

Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

the CVE list would disagree with you.

https://en.wikipedia.org/wiki/The_Power_of_10%3A_Rules_for_Developing_Safety-Critical_Code

and their 40 page coding standard document. https://ntrs.nasa.gov/api/citations/20080039927/downloads/20080039927.pdf https://ntrs.nasa.gov/citations/20080039927

and their software safety handbook. https://standards.nasa.gov/standard/nasa/nasa-gb-871913

all 389 pages of it https://standards.nasa.gov/sites/default/files/standards/NASA/Baseline/0/nasa-gb-871913.pdf

It's also just a huge fallacy. He's saying that people just choose to not write memory safe code, not that writing memory safe code in C/C++ is almost impossible. Just look at NASA's manual for writing safe C++ code. It's insanity. No one except them can write code that's safe and they've stripped out half the language to do so. No matter how hard you try, you're going to let memory bugs through with C/C++, while Rust and other memory safe languages have all but nullified a lot of that.