vonsnowman

A very valid concern. We will work on this.

A big advantage of LF-delimited over length-prefixed messages is netcat/telnet-friendliness. That was more valuable to us than being binary-clean as our use cases do not involve sending large binary messages.

Netstrings look neat although I find the use of a redundant comma delimiter somewhat confusing.

Buffer overflow concerns are not applicable to SSMP however, as the spec explicitly restricts message size to a maximum of 1024 bytes.

Client auth is explained in more details in the spec: https://github.com/aerofs/ssmp

Our most common use case is client certificates but there are provisions for alternate auth schemes.

base64 is the preferred way but any 8-bit encoding that doesn't use LF would also work.

There is no support for a length header or chunking as SSMP is designed with small messages in mind.

Not currently but we'd love to do it if there's enough interest to justify a more formal standardization.

At first glance:

  - golang-builder does not provide a convenient script, instead requiring manual
    docker invocations [more flexible but more cumbersome]
  - golang-builder uses volumes, which makes it very hard to use within a container
    [may not matter to everyone but it certainly does to us]
  - golang-builder uses a significantly larger base image
  - gockerize has a really nice logo ;)

We're not doing anything too fancy. Basically, we spawn a container to build a statically linked binary and do a regular Dockerfile-based build inside that container. The result is an image which contains only a single binary (any maybe some static assets like config files or images).

We're planning to open source our build script shortly.

This isn't so much Java vs. Go as it is JIT/interpreted vs. AOT-compiled. The numbers are entirely typical across a wide range of such comparisons. [...] while an app written in C++, Rust, or Go will take 2MB. Agreed. As mentioned in the blog post, I considered Rust but decided against it because of I found it much less mature than Go. I did not consider C++ because, as mentioned in the blog post, part of the point was to experiment with new language/tools and even though I consider myself proficient with it, I learned the hard way that the lack of memory safety is rarely worth it.

I suspect that the 668MB Java image was at least 90% unnecessary garbage that was not actually needed at runtime. Unfortunately the package managers we all use are not optimized for containers Exactly. That was part of the point of this blog post, which I may not have been successful at getting across. Switching to go was, if not the path of least resistance to solve this issue, at least one of a few relatively easy routes. It also happened to be a great deal of fun.

Hehe, yes, I'm afraid I have a proclivity for terrible puns. I do think they're somewhat less cringe-worthy that the link-bait titles that are all the rage these days (or at least endearingly cringeworthy).

Basically Ubuntu 15.04 docker image + openjdk8 + mysqlclient + the service itself

The footprint of this particular service could have been optimized in Java but:

  1. the JVM itself imposes a high floor (hotspot, many shared libs loaded, ...)

  2. the Java language is full of overhead at every level (boxed types are a pet peeve of mine)

  3. the Java ecosystem has a tendency to regard memory as an inexhaustible resource, which lead a lot of waste in many 3rd party libraries

Optimization was the original goal, increased maintainability was a pleasant result.

As mentioned in the blog post, this was a hackathon project originally, hence the motivation to start with a very small server.

The other servers that went through a rewrite also ended up being significantly smaller in go but that's a story for another day.

At this point we have 6 microservices written in go in the appliance:

  - team-server probe: already mentioned in the blog post.
    Determines if any installed Team Server is down.

  - ca: as mentioned in the blog post, as simple Certificate Authority

  - charlie: a checkin service. Desktop clients periodically post to it
    to signify they are up. This data is used in each user's device list
    to show if the device is up and which ip it was last seen from.

  - auditor: takes audit event in an HTTP endpoint and forwards
    them to a raw TCP connection as expected by splunk and co

  - valkyrie: a relay server used for data transfers when desktop
    clients cannot establish direct TCP connection (more about that
    in a future blog post)

  - lipwig: a messaging/pubsub server used for peer discovery
    and notifications (more about that in a future blog post)

Go all the way to appendix B for the serious part.

It's interesting how, besides the obvious jokes in every other sentence, the paper is otherwise almost plausible.

I value coworkers whose company I enjoy and who genuinely care about making customers happy. There's a wide spectrum between detached paycheck collector and over-invested lifer that fails to notice anything outside of work. I have nothing against people on either end, it's just not the kind of work environment I'm looking for.

I don't think culture has been a major issue for us when hiring. I merely brought it up as a counterpoint to the "just raise the salary" argument which strikes me as disingenuous.

Such anger.

I don't recall claiming to make the world a better place. We've changed our focus since I joined and to be honest I was more excited about the original vision but I'll take corporate file sharing over online advertising any day.

Then again, I'd take life as an itinerant purveyor of french toast and fine liquors over online advertising so I'm hardly representative of the average person in this "industry".

Don't get me wrong, the terms of the H1B are pretty terrible but that should not detract from Yuri's point that quotas and other immigration restrictions have a serious impact on smaller companies' ability to hire the best employees.

Similarly a lot of people talking about salary are missing the point. Sure, there might be more candidates if the salary offered were higher but even if they had the right skills (and that's a big if) they might not be a good fit for the team.

I know mentioning "culture fit" may attract a lot of flak but consider this: if a candidate cares more about the salary than the product and the team then even if they're incredibly skilled they risk being detrimental to the company as a whole. I've seen what the world of finance looks like through some friends and it's not pretty.

Or, you know, keep the person they've been training for 2 years and that is now the most knowledgeable about some sizable chunks of the product...

FYI, I am the employee mentioned in that post and your statement is just hilarious.

Obviously, a young French guy with disposable income, no dependents and earthly possessions that fit in a large backpack and a suitcase is not representative of the majority of H1B workers but the specter of deportation is not very scary to me. The last two times were just opportunities to travel.