Scala – 1 Star – Would Not Program Again

http://play.lighthouseapp.com/projects/82401/tickets/98

I loved Play 1.x(early adopter also) but I have since moved on. I gave Play 2 a solid chance. Scala programmers seem to turn everything into some kind of academic paper.

An immutable List of Foos is a List of Bars if a Foo is a Bar. A function taking X and returning Y is a function taking A and returning B if A is a X and Y is a B.

It's just answering the question "Can I use type relationships to guarantee that I will have no run-time conversion failures?"

rust-http is, at present at least, rejecting the standard practice of stringly typed headers and is using strongly typed headers.

> ... and even types for every ‘known’ HTTP header.

> The known HTTP header part was particularly ridiculous. HTTP headers are defined as simple key/value pairs. You’re supposed to be allowed to add arbitrary headers. You’re not supposed to be constrained by the framework you’re using not having any support for CORS yet.

He has taken a strong position against this strong typing; I take a similarly strong position for such strong typing.

Yes, HTTP headers are defined as simple key/value pairs. But headers are not text; they are data. XML is defined as text. Should we use regular expressions to work with it? (True, it also has the DOM defined. But HTTP headers also have a grammar defined—it just happens to include the admissibility of extension headers.)

HTTP is a serialisation format for messages; messages made up of computer-readable data, not text.

I wrote a handful of paragraphs about this subject at https://github.com/chris-morgan/rust-http/issues/1 where using a map instead of typed headers was suggested.

As I also note there, I would not attempt such a scheme in a language like Python (my primary language for some years) because its type system is not well adjusted to something like this; I am certain it would cause many problems and feel it likely it would cause more than it solved. But in a language with a solid type system capable of expressing these things, taking advantage of it should lead to a faster, more correct program.

In the end, I believe strongly typed headers are a good thing to have (it will actually make most code distinctly nicer—e.g. ``response.headers.date = Some(now())`` instead of ``response.headers.set("Date", now().to_http_header())``). The implementation of the scheme in rust-http is certainly not perfect yet; I'm not happy with it at present; I'm expecting to turn the extension headers into a trait object, and I've even considered crazy ideas like allowing users of the library to make their own header collection (request.headers and response.headers) types—that would allow custom headers to be made first-class citizens but could lead to compatibility problems.

Still, I don't want to make something that I believe should be the best HTTP library around and find that people hate to use it. What do you think about this header matter?

In Java's OO paradigm, instance variables are inherently defined separately from their initialization, making it quite difficult to make sure they're always used when initialized, properly.

The nullability stuff bites me over and over :(

Forgetting to use .start() on a thread is a stupid runtime error, instead of using some design where it isn't possible to forget .start() or at least get a compile-time error.

I am also using a lot of C in parallel, and with the C preprocessor, I am finding that C is often more expressive and nicer to use than Java!

Everything takes ridiculous amounts of code.

For example, in Haskell, I can write:

  threadIds 

  if(msg.what == Foo) {
    msg.obj1 ...
    msg.obj2 ...
  } else if(msg.what == Bar) {
    ..
  }