usrbinbash

12 ms·

361.
by usrbinbash 3y ago
What should we accept? That every library is made under the assumption that it has to work as expected, even if people ignore the documentation? As someone who made and maintains multiple libraries: No. Not gonna happen.
362.
by usrbinbash 3y ago
> You are literally putting forth arguments in favour of fixing the thread safety issue, and then conclude it’s not worth the effort. Yes. I do. These two concepts don't contradict each other. > No it’s not a performance problem.
363.
by usrbinbash 3y ago
> And yet the mainstream consensus is that C and JavaScript are terrible languages with deep design flaws. Oh, they all have flaws. But whether these make them "terrible" is a matter of opinion. Because they are certainly all v
364.
by usrbinbash 3y ago
> Why not fix the problem? Because doing so breaks backwards compatibility, simple as that. The problem isn't even that `setenv` isn't thread save. The problem is that `getenv` returns a `*char` directly into the environment me
365.
by usrbinbash 3y ago
The fact that there is an alternative doesn't change the fact that a lot of software relies on the worse method to work.
366.
by usrbinbash 3y ago
That is an unpopular opinion for the simple reason that some programs do in fact need to set envvars, particularly programs that will start child processes.
367.
by usrbinbash 3y ago
> C Doesn't Want to Fix It Or: C knows that it doesn't need fixing. How often do I need to `setenv()` anything? The answer is "Never" in the vast majority of programs, because ENVVRS are usually read rather than set
368.
by usrbinbash 3y ago
I certainly didn't miss that, as I pointed out myself: I use naive datetimes in my codebases. Alot of them. And this change generates quite a bit of work for me. But I'm okay with that. The problem with de facto standards is: Th
369.
by usrbinbash 3y ago
> To me it is clear that the Python maintainers behind this deprecation have a problem with naive datetimes and are using this supposed problem as an excuse to cripple them. I am not a python maintainer, and I also use naive datetimes a
370.
by usrbinbash 3y ago
> In twenty years the industry will look back on golang as an avoidable mistake And here is my opinion: I think in 20 years, Go will still be a mainstream language. As will C and Python. As will Javascript, god help us all. And while all
371.
by usrbinbash 3y ago
> There were complex class hierarchies, patterns that weren't documented but had to be followed, interfaces from 10 different packages, really hard to grok names, magical DI, Lombok, complex mock testing all while 10 different linte
372.
by usrbinbash 3y ago
Goroutines blocking is normal procedure in a a Go program. It also isn't a problem, unless my code is broken and allows all Goroutines to block simultaneously...in which case the runtime automatically terminates the program with a Dead
373.
by usrbinbash 3y ago
Yes, having a good backing by a huge entity is a bonus. But it's not a guarantee for success either. Google+ anyone?
374.
by usrbinbash 3y ago
> We're suggesting that people should just use Rust (or Haskell, or F#, or any other robust functional programming language) instead. And how well did that work out for Haskell? https://gist.github.com/graninas/
375.
by usrbinbash 3y ago
Nothing, the question is whether it is important enough to be included in the language. Just because person A thinks this is hugely important, doesn't mean person B has to agree, or that B is a bad developer.
376.
by usrbinbash 3y ago
> It was designed, specifically, as per Rob Pike, for _bad_ developers. Mind showing us the source for that? Go wasn't made for incompetent developers. I'm fairly certain that people who land a job as devs at Google are pretty
377.
by usrbinbash 3y ago
>It's amazing how confident they are due to the compiler having their back, and how confident I am their code won't blow up that much in prod. I get what you're saying, and I'm glad you are having such a good experien
378.
by usrbinbash 3y ago
> with LLMs where it is able to declare a novel function and then use it. Novel as in "implements a new algorithm that has never seen in any form and is actually an improvement over existing methodology"? Here is a little thoug
379.
by usrbinbash 3y ago
Well, Brainfuck is simple to learn. The entire specification fits comfortably on a single page. Simple to learn doesn't automatically imply simple to use for any given purpose. The same is true for Go. > You have to use an interface
380.
by usrbinbash 3y ago
> This is a false dichotomy. One does not imply the other. No it isn't, and yes it does. By definition, the more features I add to something, the more complex it becomes. So yes, Go achieves it's simplicity precisely by leaving
381.
by usrbinbash 3y ago
By definition, every bit added to a language makes it more complex to learn. Sure, it could be done. Lots of things could be done to Go. The people who invented it are among the most brilliant computer scientists alive. It's a pretty s
382.
by usrbinbash 3y ago
> ignoring decades of programming language True, and because of this, the language can be learned over a weekend or during onboarding, new hires can rapidly digest codebases and be productive for the company, code is straightforward and
383.
by usrbinbash 3y ago
We also understand, down to a very very very microscopic level, how neurons work. We also know a helluva lot about the architecture of the brain. Does that mean we can explain our own intelligence, how our minds actually work? Nope.
384.
by usrbinbash 3y ago
> You would realize that all we are doing is using statistics to predict what the next item might be. Two questions: 1. How can humans come up with novel ideas then? Statistically predicting the next item means I am limited to the traini
385.
by usrbinbash 3y ago
> Isn't that exactly how humans learn to respond to stimuli? Maybe it is, maybe it isn't. Maybe we are "just" an incredibly powerful prediction engine. Or maybe we work from a completely different modus operandi, and
386.
by usrbinbash 3y ago
> Van Allen had budgeted £100 for the job, and come in under. I have a question to people in charge of politics everywhere: Given how much money governments spend on nonsense, why can't we take some money, and build simple, but qual
387.
by usrbinbash 3y ago
> It's very resource intensive and challenging to design multiple interfaces Sure is. Wanna know why? Because there is no unversal standard on how to do it. And arriving at such a standard is really really difficult, in no small p
388.
by usrbinbash 3y ago
> The fruit is low-hanging This is basically the only part of your post I disagree with, for reasons you pointed out yourself. Low-hanging-fruit would imply that it is easy to displace these flawed languages with something better. And yo
389.
by usrbinbash 3y ago
> part in my comment you perhaps missed. I didn't miss any part of your comment. The line you quote was as a reaction to the alternatives presented immediately after that part. Because why would I sacrifice the advantages of semver
390.
by usrbinbash 3y ago
Or I could just accept that neither numeric, nor string ordering works for semantic versioning, and write a trivially easy piece of code that does the ordering in a contect where I expect such a scheme. > If we wanted trivially comparabl

More ›