dmacvicar

I think D has a completely different of issues starting by a) small community b) reference compiler is not fully free software c) free compiler (ldc) is not finished d) very few people work on both compilers, etc.

I understand what it is.

I don't see the need of it if you already have a class-based system.

Go uses structural typing. But it is the only thing they have. Rust has traits, and it is the only thing they have.

I can't think now of more stuff but I remember you could even write xml in the language.

I mentioned I haven't used it, I only got the impression from the API, but you are criticizing the implementation right, not the API?

As the author of this post mentioned the culture of the Java developers, the "architect" thing and the frameworks, Scala has its own similar problems: it attracts a group of academics on type systems and creates over-engineering in a completely different direction.

Also, while I think Scala is simple at its core concepts and syntax, it gets complex because it has too many features and tries to support all features present in other programming languages. Why do you want structural typing there?.

Also, I hated sbt.

Yes, but gcc requires gcc and THAT is. gcc does not require KDE and apache to build (which is like Maven dependency chain looks like).

I think I already mentioned why Linux distros build the entire chain from source: they provide support for it, they need to be able to patch it and they can't take responsibility for binaries built in an unknown environment.

However, I don't understand why you mix two things: maven concept and design (which is fine) with what I criticized: a build tool that depends on everything that it intends to build in the first place.

That is why I don't understand the "enterprise" sticker they try to put on some Java stuff.

Building without network connection was a feature most of these enterprise "build tools" did not get right from the beginning.

Patching a dependency, rebuilding the affected chain and ship it back to the customer is something I still ignore how the Java ecosystem does with their native tools.

Probably they just do "mvn" in their workstations and .zip the output folder.

I did the two FP courses from Mr. Odersky using Scala as the main language and then continued playing with the language for small experiments.

While the language is awesome in general, I would not recommend it at work.

There are several examples of simple libraries in Java that makes you realize it is possible to provide solutions to problems without the "culture" that predominates the ecosystem.

For example Simple (http://simple.sourceforge.net) is a great XML serialization framework that does very well what it is supposed to do.

And there are others I haven't used, but you look at the API and think, this is what I want.

I was very impressed with jDBI (http://jdbi.org/) even if we could not use it because of Maven.

While I have seen what you describe, I am not sure if it is only specific to Java, and I have to admit that I enjoy working with the Java platform. There are things in the ecosystem that annoy me more.

We use Java in a non-standard environment: products built on a enterprise Linux distribution, and therefore built using the same infrastructure and conventions: everything is built from source as a dependency chain, so that you can patch it and provide support, and ship those patched components back as packages. Everything is built in a repeatable environment, jailed in a VM, no network, that only contains the dependencies you declared.

So there were those nice times where building a Java library meant packaging 2 or 3 dependencies, then packaging the library was as simple as unpacking, apply any patches, set the classpath to the dependencies and run ant. Then install the resulting jar. It played well with the environment.

Java build tools are insane.

To build most libraries I now need Maven. Maven needs like a hundred dependencies to build, plus some plugins that need those dependencies, and those plugins build with Maven, the dependencies too. At the end, to build Maven, you need to have all components which are the reason you are building Maven in the first place.

So this makes me thing Java developers don't think in terms of layers, and they pull dependencies without balancing the costs (writing one function vs depending on 20 more jars).

A build tool should have almost no dependencies outside of the base system (in this case the JDK) and the compiler.

But no, they added even a Dependency Injection container. And now they realized that the one from Google is better, so they switch to it, but without removing the old. So now they may be depend on 150 packages instead of 100. Great. Lets add more stuff.

Imagine if to build make you need to have Gtk, and a library that builds with cmake and another library that builds with scons.

And all the noise with this advanced nuclear engines and frameworks to power something as simple as a build tools is at the end useless. At some point the project still declares technical bankruptcy and dies. Java has a lot of "choice" in terms of libraries, but a good percentage of them are dead projects.

Each language having its own tools is fine and I doubt OSes are against that. Those tools just need to support a very specific set of features or scenarios to make packaging easy:

Understand that enterprise OSes are not built on developer Macbooks. Enterprise distros have reproducible builds on automated systems with chroots that contain only what the package needs, no network access and sometimes the build happens inside a virtual machine. Its is almost ridiculous how after maven forgot the topic of being "offline" almost every tool released afterward has done the same mistake.

Understand that Linux distributions sell support and that means being able to rebuild a patched version of a failed package. So whatever dependencies are pinned in Cargo.toml or Gemfile is irrelevant. The OS maker will override them as a result of testing, patching or simply to share one dependency across multiple packages. Distros can't afford having one package per git revision used on a popular distro and then afford to fix the same security issue in all of them.

So having "cargo build" be able to override dependencies and instead look on the installed libraries with a command line switch or env variable helps the packager not having to rewrite the Cargo.toml in the package recipe.

Maven was probably the first tool that made packaging almost impossible and completely ignored the use-case of patching a component of the chain and be able to rebuild it completely.

Semantic versioning is great news, because it allows you to replace the dependencies for a common semantic version (not exactly the same).

For integrating with the C libraries not much needs to be done. If you support pkg-config then you cover 85% of the cases.

For curiosity. Does Valencia and Balearics use the .cat domain?. They seem to call their Catalan "Valenciano", even if it is the same language.

As a man married to a Catalan girl. Be careful where you are going :-).

I love my X220 (work laptop). I use it as my main machine at work with the dock and two monitors. It is fast, responsive and very portable and the Intel graphics just work on Linux.

But I have a T410 at home and I am not very happy with it. The dock is unstable, it disconnects, USB dies. The stupid dock blocks the fan, and you do anything cpu intensive and it end shutting the system down because of temperature. The NVIDIA graphics never worked reliably with nouveau + dock + suspend (I have to use the binary driver).

And worse, it is an i7 (x220 is an i5) and it feels so slow compared to the x220.

Nuremberg, Germany here.

http://en.wikipedia.org/wiki/Nuremberg_U-Bahn#ATC_and_driver...

We have driverless trains without drivers at all. There is some staff getting into random trains to check for problems (like problematic passengers, etc).

Interesting thing: the migration is going gradually, there are trains with drivers running on the same line than driverless trains, and IIRC this was never done before.