apta

60 ms·

631.
by apta 7y ago
You have a regulatory authority step in, and allocate the masks to people who need them (e.g. healthcare workers). Sales from individuals are banned, and said authority can buy them back from people who own them. Just like how the governmen
632.
by apta 7y ago
This is why people are against blind capitalism. Not everything is supposed to be unconditionally placed in the supply and demand curve. Price gouging is immoral, especially when people's lives are at stake.
633.
by apta 7y ago
It has already caused several issues in golang, and this is an example: https://github.com/golang/go/issues/16474
634.
by apta 7y ago
> People were using their student loan money in their brokerage accounts Doesn't sound like the smartest thing to do.
635.
by apta 7y ago
> Don't want your society transformed by outsiders by force? Don't start wars with them that you're going to lose in the end. Iraq was invaded by the US and its allies, especially in 2003, under the guise of baseless WMD.
636.
by apta 7y ago
It's quite egregious how the US thinks it has the right to force a regime change in any state it chooses, and that "secular" and "democratic" is always the answer. This is an extremely Western biased, and sorry to s
637.
by apta 7y ago
golang does nothing to solve NPEs, and any line of golang can panic at anytime. At least with Java established frameworks have exception handlers at the base where relevant exceptions can be logged or handled in some other way. With golang,
638.
by apta 7y ago
Just because you haven't seen it doesn't mean it doesn't exist. It's very easy to mishandle errors in golang, I've seen it several times now.
639.
by apta 7y ago
Those linters won't catch everything. There are cases that will slip by. Rust's error handling, as well as exceptions are both strictly superior to golang's error handling.
640.
by apta 7y ago
No it won't: fmt.Println("foo") You're not forced to handle the error. Not to mention more obscure cases like a, err1 := foo() if err1 != nil { return err1 } b, err2 := bar() if err2 != nil { r
641.
by apta 7y ago
golang's philosophy leaks everywhere, many things are half-baked for no good reason, even when strictly superior solutions are there (e.g. defer works at the function scope, instead of the local scope). Not to mention interfaces are ba
642.
by apta 7y ago
Even if golang gets generics, it has so many other flaws that make it an non-starter for serious projects. This won't stop people who are driven by hype from using it of course.
643.
by apta 7y ago
golang's broken interface design also encourages hacks (which lead to difficult to track down bugs) like this: https://github.com/golang/go/issues/16474
644.
by apta 7y ago
It's disgusting how much power is being given to corporations that do nothing but strictly harm the population. Not only is the tobacco industry directly harming people by selling them poison, but all the pollution being generated by w
645.
by apta 7y ago
You can't cast a type to an arbitrary interface and hope that it implements the method(s) you want to call in Java or C#.
646.
by apta 7y ago
Fiat currency, coupled with an economy based on usury (aka interest), is definitely not sustainable. It's scary to think about what may happen when it all comes down.
647.
by apta 7y ago
It worked despite of it, not because of it. People can write large programs in assembly, can they not?
648.
by apta 7y ago
You get problems like this, which you don't get in traditional OO languages: https://github.com/golang/go/issues/16474
649.
by apta 7y ago
> The evidence for this claim is that the designers claim it, that's totally sufficient My argument is exactly that, their claim is unsubstantiated, and people's experiences in practice contradict their claims. Not to mention t
650.
by apta 7y ago
It gets in your way when you're debugging or writing quick scripts.
651.
by apta 7y ago
The fewer ways just means that now you have to jump through hoops to fight against the language, ending up with more complicated code bases (and this has been observed in practice). > People often laud the relative ease of picking up the
652.
by apta 7y ago
Seems like you haven't worked with actual large scale golang code bases then.
653.
by apta 7y ago
The standard of evidence is what I see when I use the language at work. And so far, I don't see much that validates the golang designers' claims to be honest. > One point would be Go's faster compile times I'm looking
654.
by apta 7y ago
> 1) Extremely fast build times (even for large codebases). Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference
655.
by apta 7y ago
You use linters to catch those issues (and more). Any quality project will have linters, CI/CD etc. set up. And it's not like golang obviates the need for linters, if anything, it needs them more than other languages to deal with
656.
by apta 7y ago
Practically any large scale project is going to have linters involved at some point. This seems to be a much better suited task for the linter to catch than to be set at the compiler level, since it severely hinders programming locally.
657.
by apta 7y ago
> Go is primarily a language for programming in the large Other than the claims they put up on their blogs and presentations, what hard evidence do we have that this is actually the case ? Java and C# are much more suited for "progr
658.
by apta 7y ago
> a protection that, until now, had to be enforced merely by convention and review. It is enforced by linters and almost all IDEs. Compare to how how the following golang code drops errors silently, and is not caught by the compiler:
659.
by apta 7y ago
> The moment there is business logic I don't want to be writing Go anymore. What do you prefer for writing business logic type apps then?
660.
by apta 7y ago
> large scale collaboration What does golang have to facilitate large scale collaboration that isn't done better in languages such as Java or C#?

More ›