> In the US, many drivers will ignore the existence of pedestrians altogether.
This is pretty limited to urban areas, in my experience. In more suburban and rural parts of the country, people are much more cautious and obedient to traffic signals and rights of way. Of course there are exceptions in both cases, but running red lights, turning into pedestrians/cyclists/etc is much more prominent in major cities. As an urban pedestrian, I just have to keep my head on a swivel because there's a good chance that the taxi/Uber across from me is going to run the light that just turned red so he can make his left turn instead of waiting for his signal.
> Cars almost always have a green in the same direction, meaning they can turn into you.
This is where you are mistaken. In the US, cars are obligated to yield to pedestrians in the crosswalk while turning, even with a green light. The pedestrian signal indicates pedestrians have the right of way. Of course, drivers may illegally fail to yield, but whether a driver obeys the law is a different matter than what the law says.
I do the same, but I do worry about the security aspect. I don’t like the idea of having a bunch of devices on my network. I put the IoT things on a guest network, but I still feel iffy about it. I’m sure there are better solutions, but all of them seem to require flashing your router with DDWRT and doing fancy networking things that I don’t understand well, and frankly I don’t want to put the effort in.
When I was doing Qt development, getting CMake to build Qt projects properly was absurdly difficult. CMake had added some half-baked first class functions for building Qt (it's insane that a build system has first class knowledge of certain libraries, but insanity is par for the CMake course), but you still had to invoke them yourself and the various docs, blog posts, stackoverflow answers, etc gave different advice about invoking them but rarely did the advice work (and if it did work, it never generalized to non-toy projects). My understanding is that CMake has improved its insane first-class Qt functions such that it's easier.
(There's also qmake, but at the time I was using Qt, it only worked if you didn't depend on anything that wasn't also a qmake project, which is just more C++ build system insanity).
I misunderstood your question. I don't know of the specific reasons; presumably they're the same reasons that intermediate C programmers can't reliably write secure C.
I think that’s what I meant as well, but I’m not sure what you mean by “service orchestration”. If Kubernetes is an example of a service orchestrator, then I think something like EC2 would be the unikernel analog.
“Container” and “OS” don’t mean anything in the context of unikernels. Unikernels are applications with everything they need to run (on bare metal or a hypervisor) baked into the application. So there is no OS to speak of, and the “orchestrator” is probably something like AWS EC2.
Fair point. Perhaps my issue was less about the visibility of the annotation and more that the types in functional languages tend to be more abstract or complex (e.g., monads, functors, etc) and harder (for me) to reason about despite the code being terser.
I actually find that excessive type inference is much harder to understand. It’s almost like the worst of dynamic and static types. You have no idea what the types are, but you know it won’t compile because of a cryptic error message.
The data was originally forked from rosettacode.org on 2019-10-22. In comparison to Rosetta Code, in RosettaGit all code is stored and hosted in a repository on GitHub instead of a MediaWiki. This has following advantages:
* Code can be edited with proper text editors
* Continous integration and delivery can be used to ensure a high code quality
* All infrastrucuture for git (e.g. GitHub) simplifies further development
* Faster load times as pages are only rebuilt after a change
I don’t think I’m the one missing the point. You seem to be rebutting points I didn’t make, like other languages (or magic bullets) afford a bug count of zero. You also seem to be ignoring my point, which is that C is in a different ballpark than other languages in its difficulty of implementing correct software.
Many of the most expert C programmers have reported an inability to write secure C code. But you’re right that my understanding of the language is incorrect; that’s largely my point. There are so many oddities and exceptions and surprises that the language is very hard to understand correctly. The people who profess to “not have these problems” haven’t written code that has run the gauntlet of security and widespread multiplatform distribution.
Linting for WithStack seems like it might be tough since you want to make sure the error was annotated exactly once (I think that’s the intended use, anyway?). The linter would need to know whether or not a fallible function call has annotated the error or not. Seems like an interesting exercise in any case.
I’m not talking about being clever, I’m talking about writing code that meets some baseline standard for security, correctness, and cross platform functionality. The issue with C is that standard, “unsurprising” code often behaves unexpectedly.
I love writing C when I haven’t written C in several years. It feels nostalgic and simple and elegant in my mind, and then I remember all of the issues I run into and how none of them have good, clear solutions. Things like writing cross platform code or string manipulation or how often things I swear I understand actually have bizarre edge cases, things I thought were well defined behavior are actually undefined, etc.
> Yes, it does. Whenever you call a function that can possibly fail, you are supposed to add:
if err != nil {
return err
}
I don’t think that’s what the parent meant by his question. He was asking if you have to add runtime checks all over to make sure any reference type isn’t nil; no, you don’t—you only add the checks for those for which nil is a valid state in the program (such as errors). If it’s an invalid state, it will panic because it’s an exceptional circumstance—a programmer error. This isn’t a defense of nil; only a clarification about how nil is dealt with. With this context, the rest of his question (the part you didn’t understand) becomes clearer.
You can abstract over a struct as easily as a pointer, and structs work fine for satisfying interfaces. Specifically, structs make it a little harder for someone to inadvertently mutate things (passed by copy) and because they can’t be nil you don’t need to worry about a non-nil interface implemented by a nil concrete pointer (this is mostly only a problem for people who are new to pointers in my experience). The downside is every time you put a struct into an interface, it gets allocated on the heap, and allocations are expensive in Go (also passing structs can be more expensive than passing pointers).
I don’t know man. I have scarcely seen bugs like these and most of them seem pretty conspicuous to me (maybe I’ve just been writing Go long enough), but I see loooads of uncaught Python (and Java) exceptions internally and from high-profile third party tools.
It doesn’t require it. Instead it could just generate the same error handling boilerplate. But I think it would be a mistake versus general purpose (generic) sum types a la Rust.
I don’t buy the “huge pain” argument. I write lots of Python and Go, and the error boilerplate is a non-issue. I also appreciate that it’s explicit instead of implicit.
It appears to be specific to Java. Other languages don’t seem to exhibit high memory usage with the same frequency or severity as Java, and that’s not because developers of other languages spend more time optimizing.
If indeed this observed memory bloat is just a matter of poorly written Java apps, then that’s even more interesting. Why does it seem like Java has such a high incidence of poorly written apps relative to other languages? Is it OOP or some other cultural element?
This isn’t meaningfully true. The monkey holding the banana is an example of standard practice OO design. The standard practice for developing a suite of libraries in Go (or indeed in any non-OO language) is to decouple them. They can still work together as a suite of tools, but they can also be used independently. Not sure if this is the best example, but I would routinely use gorilla/mux on its own.
They are objects with a reference to the gun that fired it and everything it could possibly interact with in the game and indeed the game itself. How else is it going to have a “shoot()” method with no arguments?