bassislife

Adding to the list the very important Kanem-Bornou Empire and Bagirmi Kingdom.

I think it was humor :)

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.

Your proposal only works if you don't need ABI-compatibility, especially relevant if the build process needs to be parallelizable.

It all depends on what sense you provide to the terms: "minor version" and how you expect your software to be built.

That's not different from having a bad leader ruling forever... That's torture. 1789 occured for a reason.

All these dictators in Africa ruling for (eternal) life ?!! What a nightmare !

Treating different major versions as different packages

For emphasis, because I think that's what should ideally happen.

If you are Seebeck, where are Peltier and Thomson? ;)

they are all defined with fmt.Errorf

No, an error implements the error interface. It means that it can be a value of any type that implements the constraint of having an Error method.

You can test the interface. A type is just an interface around memory, albeit more consrained.

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.

We can already create multiple ones.

Release the Hounds.... The Hounds have been released. Go is released seems fine to me.

Anxiety is probably environment-induced. Kids are not necessarily so anxious.

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.

For category theory, I don't think so. But if we take tensor algebra, of course, in physics, especially quantum mechanics .The thing is, you could approach the same physical problem at different levels of abstraction and would therefore use either or. For the study of manifolds, people generally tend to favor tensorial analysis. But some results could be found within the framework of category theory.

In terms of seminal work, I admit I am quite ignorant. I would check with SIAM.

But maybe monads are too exotic to provide a good example.

Nah, it's fine.

But a monad is just a part of an abstraction. Which also means that they have been used without that specific denomination for ages.

The use of Category theory just allows to think about things out-of-context but it is not necessary nor evident that it "always" leads to interesting results for the everyday programmer.

It is like the difference between applied and pure mathematics.

The concept of a monad in haskell was introduced to solve a specific problem though, if I remember well. And it was not uncontroversial. But people who know better could chime in.

Well maybe an example of something related to the game of Go written in Go should be planned in the future then. :)

so "=== gefahrlos" ?

less dangerous? or "not more" dangerous?

What if one simply says that a monad describes a pattern of morphisms composition ? Adjunctions being the plumbing ?

(honest question, just trying to find a simple, grokkable definition)

I think the assumption is that the hardware spec is correctly implemented and that it runs ideally well. Otherwise that would require some kind of probabilistic model I guess. But you're right, "purity" is a simplification. Computations are inherently effectful(and even side-effectful depending on the reference frame) in practice.

Also, I seem to understand that the research is merely done in the context of the Rust language. The title is maybe a bit too much :)

AFAIK struts+arrays in C# are the only construct I've seen

or Go, especially with the value types. Now there is no automatic SoA/ AoS conversions but otherwise, you have full control over memory layout.

shrug At least our language designers trusted our intelligence enough to implement generics.

Trusted you so much that they even tripped on co/contravariance to add to the challenge :p

which LLVM now supports

Key word being "now".

I think you understood rather well.

Also have a look at the supported architectures paragraph in the documents you linked.