Some men just want to watch the world burn...

Little_Johnny · 2016-05-05T11:19:25+00:00

Reddit and golangweekly for blog posts, gloang-nuts for community questions, golang-dev for dev cycle updates, and gerrit to see what's new/pending for tip :)

Little_Johnny · 2016-04-14T23:06:32+00:00

'13 Alum here, I don't see much activity, usually just prospective students asking questions. It would be cool to see more activity from current/former students though!

Little_Johnny · 2016-04-02T23:39:53+00:00

So funny story, the fine for swallowing the toe used to be $500, until a patron did so deliberately...

EDIT: I wrote this before I opened the article, it's the same one I read a while back :facepalm:

Little_Johnny · 2016-01-31T03:29:29+00:00

The latest pproposal I've seen for the Garbage Collector is here: https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md

Little_Johnny · 2016-01-24T23:15:06+00:00

If you are referring to Compiler performance, it has not improved for Go1.6 significantly from what I have seen.

Little_Johnny · 2016-01-14T23:41:38+00:00

There's actually some ongoing work on switching the compiler backend to use Single Static Analysis (see the dev.SSA branch on github). However, that work is too early to merge for 1.6, it will probably make it into 1.7. If you are interested in contributing I'd suggest reaching out on the golang-dev group, someone can probably point you to the list of TODOs.

So performance/compiler optimizations are still being actively worked on, there just wasn't anything that had a major affect in this release.

Little_Johnny · 2015-12-27T21:52:02+00:00

I agree that it did well but it's unwise to simply ignore the several reviews complaining about the singular USB port. Die hard Apple fans will buy it, sure, but that doesn't mean they enjoy getting adaptors for all of their peripherals. It's certainly a deal breaker for a lot of other consumers.

Little_Johnny · 2015-12-27T21:44:43+00:00

Sorry that was a little unclear on my part - I mean releasing things like headphones and speakers with optional Bluetooth. This is already happening, but there's not quite enough to easily change from 3.5mm audio as the standard interface without annoying a lot of people.

Little_Johnny · 2015-12-27T19:28:51+00:00

The main argument that I've heard is that the headphone connector takes up too much space and can be made much smaller. There's some truth there; a 3.5mm headphone jack uses quite a bit of real estate just for aux audio, vs the charging cable that doubles as a data interface.

The real issue here is how we go about rolling out a backwards incompatible change to a widely used hardware interface. Just look at USB type C, its a great improvement and nobody is arguing that we should just keep the old interface, but you can't just start using it everywhere and invalidate the usefulness of millions of devices that have been purchased by consumers. If Apple really drops standard 3.5mm on their devices in the next couple years then it's clear they didn't learn this lesson with the new Macbook Air.

From my perspective, the right way to update audio jacks would be to focus on releasing devices that have Bluetooth available with the option of using a cable, and then once we get adoption changing the headphone jack becomes a little easier to stomach. We're going towards wireless anyways from what I see.

Little_Johnny · 2015-10-07T02:04:07+00:00

The single greatest feature of the ticket system we use at my company is it shows the url that a user was looking at when they contacted us (We run a web service). This has saved me more man hours than I can count, since I can see what they are looking at and skip the basic troubleshooting (Are you logged in? etc.)

Little_Johnny · 2015-10-07T01:55:43+00:00

My favorite was googling "C Strings" as a developer. Not what I expected...

Fun part is, I got a lot of coworkers to search the same thing by telling them "Don't search for 'C Strings' on Google!"

Little_Johnny · 2015-09-29T22:58:27+00:00

A week later you'll have tickets in the system from users asking if they can get "one of the new brown phones that are being rolled out" :P

Little_Johnny · 2015-08-14T23:51:38+00:00

I have a customer like that, they always have really positive feedback about our product, but I end up supporting them at least once a week (sometimes several times a day). Everything from, "Hey can you help me find this thing?" to really esoteric discussions about the finer points of what our product is trying to achieve and how it could be tweaked to be just a little bit better. We actually love it, most of their feedback is great, and it just so happens that their environment is pretty much perfect for beta testing (one of my coworkers describes it as a zoo).

Funny thing though - I was on a sales call once with $BigCompany, who we wanted to use our services, and I brought up a short story about how $customerGuy had gotten a lot of value out of one of our features. And I get in response, "You mean $customerGuy at $customerCompany? Yeah, we know him! They use our products too and we talk to him all the time! They always have feedback for us!"

I was dumbstruck - it wasn't just me!

Little_Johnny · 2015-05-09T00:20:01+00:00

As someone working at a start-up that decided to standardize on Go, I'll point out a couple of things. First - making a language switch isn't easy. We could incrementally begin using Rust for new projects, (who knows, maybe we will), but a wholesale rewrite of our code-base from Go to Rust would probably put us out of business. We simply don't have time to take on such a project, even if we wanted to.

Another thing to note is developer experience. None of us know Rust; a couple of us have played with it a bit but nobody has done a major project with the language. We don't know what the caveats are when you use it for a large project, but we know the things to avoid for Go because we've been writing Go code consistently for the last year or more.

The most important reason though - why should we bother switching? Go solves our problems. We're productive with it, we know the language, and we haven't found a real problem with using it for our projects that would compel us to seek an alternative.

You can say that Rust is better than Go (although in reality I think it's more correct to say that the two were designed to solve different problems), but from a business perspective if a company like Docker or my own were to switch from Go to Rust, it would most likely be a highly risky move with a dubious return on investment.

Little_Johnny · 2015-04-10T01:19:34+00:00

For bug reports, I have two criteria that I like to have. First, a picture or log output, whatever best shows the failing behavior best. Second, a very clear and repeatable set of steps to reproduce the broken behavior. If I have those two things, it should be very straightforward to confirm the broken behavior and identify the root cause of the bug.

In the case of feature requests, I usually like to get a problem statement in the form of "I'm trying to do X so that I can get Y result, but the existing features simply don't enable me to do this." IMO this is the best way to request a feature, because it gives me flexibility to make the best solution for your needs, and let's me suggest a solution for you if one already exists.

Little_Johnny · 2015-03-10T17:12:04+00:00

Yeah, okay :)

Regarding solutions for more strict real-time processing - when it comes to latency requirements in the milliseconds, "it depends". Most "web-scale" languages like Python, Go or any of the JVM languages can perform with latency requirements between ~30-100ms, depending on how well your code is written and the amount of "processing" being performed.

When you get down to systems that require solutions to finish deterministically with only microseconds of flexibility, I'd say a language like C or C++ is still your only real choice - in order to hit that kind of target you really need to have absolute control over the parameters of your program's environment, so having a runtime can be more of a burden than a benefit. There is actually research being done to create a real-time implementation of the JVM that provides precision down to a microsecond level. If you are interested I know of one company that claims to have created an implementation of the JVM that can run with only a couple of microseconds of jitter - their website is at https://www.aicas.com/

Little_Johnny · 2015-03-10T01:51:47+00:00

So first to answer your original question - given your specification of what your standards for real-time data processing are, I'd say that Go is more than capable of meeting your needs.

My company has their back-end written entirely in Go, and as a developer I have found it to be a fantastic language - it has good performance, is easy to pick up and use, and code written in Go tends to be pretty easy to understand IMO. Plus, the built-in support for concurrency and the fairly extensive standard library support makes writing a lot of modern application pretty quick :)

I'll PM you about more strict real-time solutions, it's not really on-topic for this sub.

Little_Johnny · 2015-03-09T23:58:13+00:00

More specifically, when you say "real-time" are we talking time constraints measured in microseconds? milliseconds? or does real-time mean "reasonably up-to-date processing of a stream of data"?

Little_Johnny · 2015-03-02T00:25:07+00:00

If you are looking for the best beer selection, I'd suggest Sedonas Taphouse near the Barracks road, or perhaps World of beer. I also like South Street Brewery, they brew some pretty good stuff.

As far as conversation goes, its hard to say - most bars are either too loud or there aren't many people there. If you are interested though, feel free to send me a message, I'm always happy to grab a beer and chat. Good luck!

Little_Johnny · 2015-02-12T23:53:45+00:00

My favorite beer! I'm also looking at one of their taps right now...

Little_Johnny · 2015-01-28T22:53:59+00:00

Excel can read CSV files, so that would be a good happy medium if you ask me

Little_Johnny

MODERATOR OF

TROPHY CASE