adamw1pl

Many people talk about Java, Go and similar, contrasting it with Scala, but I think it misses one crucial point. Java and Go are in many ways "done" languages. They evolve very little. Correct me if I'm wrong, but I don't think Go changed significantly since 1.x. Java hasn't been evolving almost at all until recently, and the changes introduced now are still conservative, and it will take ages before the ecosystem catches up and actually makes good use of what's introduced in Java 11+.

On the other hand, yes - Scala is in many ways a research language. It's got a number of novel features, starting from the blend of FP and OO, through implicits, ending with metaprogramming. The dark side of introducing features that other languages don't have, is that they sometimes need polishing or complete removal. That impacts the compiler (which evolves as well - compiling Scala code is much more complex than the rather straightforward translation of Java to bytecode) and high-level language features alike.

The bright side is that software engineering is very far from being a "done field" (or at least I refuse to believe it is such). There's a lot to be discovered as to how we can write code that is readable, performant and - yes - maintainable.

"Wait, but if you said Scala is a research language, is it safe for business usage?" Yes - while Scala has a research side to it, it also is a language used successfully in many companies. It has a lot of libraries that are maintained, the language authors pay a lot of attention to binary compatibility (with well-defined limits - you know what to expect!).

Businesses have benefited from using the newest available technology in many fields, and I doubt software engineering should be different. Of course, you shouldn't be reckless - but using technology from 20 years ago "just to be safe" isn't always a recipe for success.

Yes, you can build great systems with Java and Go. Same is true for Scala. And yes, you can build totally unmaintainable systems in Scala, but in Java and Go as well.

Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free. You like the library, it solved your problem - great, you can use it for free. But if you want it maintained above what the library author donates, either through their time or through corporate sponsorship - well, you can't have any expectations here. I'm sure a lot of these migrations problems could be solved, given a reasonable business offer.

Not yet, but that's one of the features we want to add after this initial release. Thanks for the feedback!

Yes, you are right! Funny how this went unnoticed for so long ;) Fixed now.

We'll be posting some on our twitter (https://twitter.com/shelly_dot_dev) for a start. Plus we'll be expanding the tutorial/help area. Stay tuned :)

No reason :) The language is of course Logo-inspired. Once we'll have an "About" page or sth like that, we'll mention Logo of course.

Thanks! Would be great to get feedback once you get an occasion.

The tutorial is only a start for what we are planning, so this is an area we'd like to work on next. Hence any pointers or ideas are welcome :)

Thanks for the feedback!

1. the background should be almost-opaque, with very little transparency. Can you share which browser/OS? Probably some missing CSS :)

2. Ha :D Maybe a grace period? Did you mostly mind the squiggly underline errors, or the red box that appears at the bottom? Giving feedback soon enough but not being aggressive is a delicate balance, there's probably room for improvement here.

Thanks for the pointer, React-forms as well as React this looks very interesting, however I think the focus there is mostly on frontend, while we are trying to approach the problem both on the frotend and backend sides.

Otherwise there are some similarities between the projects.

We would be fine using existing frameworks and their form handling systems, but all of them feel very heavyweight. Either the backing objects need to be of some specific form, or the communication protocol between the server and the client is weird, or the generated markup is a mess.

With Supler, we want to make it easy to customise the form, the form's markup and associated Javascript (to add any dynamic behaviour), so that you don't have to hack the framework, but instead so that you can use our library to generate the base and then customise further.

One of the main points of Supler is that it takes care of both the frontend and the backend, so I don't think it would be possible to keep it entirely on the frontend. E.g. you define the form once, and you have partial validation on the frontend, and the same full validation on the backend (without having to repeat yourself).

Maybe we should target a .NET DSL next then ;)

That's on purpose, of course ;). But it's not only marketing: functional as in preferring immutable data structures, and reactive as in changing the form in response to user input.

Let us know what you think about the DSL itself.

I'm also not sure how the above projects relate. As far as the scope of the blog goes, Apollo seems to be ruled out as it is not replicated.

ActiveMQ does have replication, but they don't really sound convincing in the docs that it's first-class ;)

HornetQ has flow control (http://docs.jboss.org/hornetq/2.4.0.Final/docs/user-manual/h...). Not sure about e.g. Rabbit.

However I'm not aware of a standard solution in that space.

Take a look at Reactive Streams (http://www.reactive-streams.org/) as well.

Agreed, a must-read :). Bottom line is all queues can loose messages (we don't know much about SQS in fact).

These are very good questions, however for a different post. Here I was mainly interested in the throughput.

Jepsen post provide some insights (into Mongo and Rabbit). With Hornet you can easily end up with two primaries. SQS is untestable in that respect :).

Yes, my bad, should be there :)

Stay tuned, I'm out soon till end of next week, but will definitely add it.

Sure, if people will be interested, we'll create an as-as-service version.

Initially a lot of companies wanted to have a self-hosted version, though.

The likes - definitely - small things can make a huge difference :).

But for me, the main advantage is having a clear to-do list, so that I can see at first glance what is still waiting for me.

I think CB can work very well in conjunction with BitBuck or GitHub pull requests.

Well, I, for one, am doing per-commit code reviews :) And I think it is working quite well for our team. The feedback loop is very quick.

Not sure what you mean by "codebrag is single-branch", as we do support multiple branches (from 2.0, maybe you tried the previous version?).

Also, SVN promoted a radically different model of working (huge commits, instead of multiple, fine-grained small commits).

I wouldn't say these two are in opposition; while CodeBrag doesn't have support for pull request, I don't see why it shouldn't in the future.

It would be perfectly valid to use CB to review commits in the branch for which the PR is done, and then come back to it once more commits (with fixes) are added.

Also, using PR is only one style of work, and I don't think it's the "only right choice". Code reviews of code as it is written, that is during development of a feature, can help you to spot any problems faster. Waiting until a PR is done can result in a long feedback cycle.

You can use CB to track a specific branch that either your colleague is working on, or maybe you are working together.

I'd say that our two main differentiators are: * a clear "to do" list: you know at first glance if there are some commits to review, and the review process is made as simple as possible, not to get in the way of the development process * code likes - let the author know that some code is good, you like the design etc. Helps to make the reviews less negative, and in the future can be a great knowledge base!