Yes, for instance, it's easy to create concurrent programs that are semantically wrong (in other words inadequate for use) albeit correct in terms of "types" because the coder made an erroneous assumption about determinism somewhere. The type systems that we see nowadays do not help with that.
"unsafety" rather ? ;)
decreasing non-safety is not the same as increasing safety. One starts with the assumption that things are safe. The other does not.
> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs.
It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language.
Especially since the systems we use are often dynamic with changing requirements.
The issue with safety is that nothing is really safe.
Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.)
So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is.
edit: since I see posts about Go, this is evidently another approach toward decreasing unsafetyness by providing fewer and easier to understand primitives so that the programming logic is harder to write wrong. It might come at a moderate cost for some applications.
It's problematic for dependency management. It's almost perfect but what would be better would be to be able to switch easily between different $GOPATH. One per project.
In Go, each version corresponds to a given import/Pkg path.
If you want to change version (major), you need to create a new package.
The advantage is that you do not have to download a manifest such as package.json or whatever.
It also provides a constraint on library authors to provide a backward compatible API for their published package.
Eventually, I guess we could use go/types to enforce/check the API backward compatibility requirement.
The main issues for now are:
* make sure that packages importing a same vendored one are able to use the same latest minor version in use.
* allow a project based approach to go get for people who need reproducible builds (or alternatively allow for multiple $GOPATH and make being able to switch between them easy)
Which I guess is normal since it does not create any dependency cycle. A new version might as well be thought as a completely different package (of perhaps similar functionality).
If there is a market for the education you received, it should.
If the job market conditions change, it might not unless the person is resourceful.
Also note that the OP is talking about the US but education is often really the key for developing countries to attain a higher level of prosperity. Because the market is still quite open there.
A very nice explanation about what covariance and contravariance mean, especially in the context of subtyping (with potential parametric polymorphism).
And implementation details are provided. An undergrad should be able to understand this.