TheHydroImpulse

We're using Docker pretty extensively at Segment with over 1,200 containers running in production with ECS (total count, not uniqueness).

We haven't touched Swarm and are staying a couple versions behind. With that said, we're pretty happy with the setup right now.

What about when they don't give that info away but keep it for themselves? Still creepy?

There is, at least for the NHL. It's still not completely reliable but I can watch every game of the regular season and playoffs much easier than using gamecenter (and cheaper). The blackouts are really bad for the NHL. When I lived in Canada, every game for every team was watchable with no blackouts. In the bay area? I can't watch any of the Canadian teams even though they're certainly not in the same market, along with Nashville, New York, St Louis, basically all of them and of course San Jose, LA, Anaheim.

It's useless. So the free streams that are available are amazing.

The reason it's slow is because python interprets it's input. It essentially introduces major indirection for instructions to be executed.

So for '1 + 1', you can't just output some fast x86 instruction and inline it. You'll usually need to jump to where the python vm will do 'a + b' in C. You're having to do a bunch of redundant work at a higher level to emulate the CPU (sorta).

That's why you have JIT compilers that will read '1 + 1' and compile the appropriate machine code, store that in an executable memory region and jump to it. First time might be slow, but after that it's pretty fast. Because you need to jump to the dynamically generated code, you usually compile whole functions at a time.

This topic is super complicated but also super interested but I tried to simplify it a bit here.

The early version of hiphop (Facebooks php compiler) would compile PHP into C++. It was really interesting how they went from C++ to now a full featured JIT.

Rc is scoped to a single thread, so it'll be, at worst, stop-the-thread.

I actually get the opposite feeling. Maybe that's because I'm so used to rustdoc now, but it's super easy to find everything. Go's doc tool seems like just a giant dump of API signatures.

Rustdoc isn't perfect, but it's pretty easy to find things imo.

Green threads are probably not going to be as useful in Rust as in other languages. Having something like await/async built into the compiler that transforms into state machine (like in C#) would be more powerful it seems.

Racer (which this package uses) supports jumping to definitions (including standard library ones).

Optionals can't be expressed safely in Go. They have a type of `Option<T>` or `Maybe<T>`. Swift just has this notion built as an operator.

Traditional enums aren't particularly interesting. What languages like Rust and Swift have are tagged unions. They let you associate data with each variant.

Moreover, pattern matching is needed to use tagged unions effectively.

Constants are not "basically" tagged unions or even enums. They are not grouped into a parent type. For example, if you have a `Foo` enum with `A` and `B` variants; while matching or accepting this, you can accept a `Foo` which is guaranteed to be either `A` or `B`.

How would Go typed constants achieve this?

How so? From my experience, I was able to make massive changes and the compiler would guide me through to make sure I didn't miss anything. If it compiles, it'll generally work minus any logical errors/changes.

> Rust is expensive to develop - if you can afford to use a GC, you should use a GC

This has not been the case for many people using Rust, including myself. Once you learn the language, there is no "cost" to use it. In fact, the compiler simplifies much of the mental overhead when dealing with concurrency, sharing data, mutability, etc... Sure the compiler has some strict rules, but it's not expensive to develop in by any means.

I would also say Rust is in a sense higher-level than Go in terms of expressiveness and abstractions.

Go effectively uses a thread-per-connection model with goroutines (M:N threading instead of N:N threading though). You won't be able to fully exploit the hardware that way.

It is, however, easier to use, but the context switching and stack overhead would be too great at anything close to 10M connections.

As long as we're talking about purely generics with no introduction to type classes, the obvious ones people point out:

- More compiler complexity - Compilation speeds might be effected - Without type inference, type signatures could be a pain point - Basic type parameters are not able to express all intents. Until you implement more complex like higher-kinded types.

Go's compiler already works with generics, although it might be built in an ad-hoc way. Either way, the complexity is seemingly already in the compiler.

Before saying "Compilation speeds might be effected", we should probably get some numbers to back that up. So I don't buy this cost right now.

The third reason is very valid as Go doesn't have type inference. You probably won't get Java's verbosity with signatures but you'll be specifying type information in a few places, at least.

They become pretty weak for encryption except #1. Moreover, there are real arguments for the inherit danger in owning a gun, statistically. It's a fact that you're more likely to commit suicide or someone gets killed because you own a gun.

You can't say the same about encryption because it's a tool, not a weapon. A gun is a weapon meant to kill.

> 2. Compromises will just lead to defeat for the pro-encryption / pro-gun side.

A compromise in encryption hurts everybody. The whole platform for electronic banking needs strong encryption, for example.

> Consequentialism: the number of people being harmed by encryption/guns is smaller than the number of people who would be harmed by living in a world without encryption/guns.

If you own a gun you are statistically more likely to get shot or killed.

Generics do not have to be complex and they allow abstractions that simplify your code.

Please explain how .map, .filter, .reduce, .pmap are complex?

Swift is also built with LLVM, a backend that is far superior to Go's handmade one. I doubt the performance issues will persist long-term.

It's not a modern Java, it's an antiquated Java. It might aim to be modern, but Go is far from being a modern programming language, even if it was implemented in modern times.

If people are still writing it by hand each time, it's a problem with tooling, specifically dependency management. If it's that much of a pain to distribute a library, then people are going to write it themselves.

That's not a reason not to include generics, however. It's an entirely different problem.

The Go community seems to throw "you're using the language wrong, do it like this..." or "copying code is the way to go" or "those things you use in other languages shouldn't be used in ours." or "I have never needed to use that in my code"

There has never been an argument on how concepts like .map, .reduce, .filter, functors, promises, futures are inferior to what Go programmers currently use. Things like simplicity are thrown around but calling these proven abstractions "complex" is wrong. That's why they're useful fundamental abstractions -- because they make code simpler and reusable.

Generics have been around for a very long time. They have been studied in-depth in academia and industry. They're universally accepted but in Go.

Generics need not be like C++ templates. There are simpler implementations of generics. They are a solution to a real problem, specifically in libraries and creating type-safe abstractions. If you don't want type-safety, then why are you using a language with static types?

- Code copying is a workaround, not a solution. - Code generators outside the compiler is a workaround, not a solution. You're essentially transpiling a language that is no longer Go into Go because of Go's lack of support for such things. - interface{} is a workaround, not a solution. It automatically shows that Go cannot express a generic variant safely. - reflections is a workaround, not a solution. See previous point.

If the Go community is happy with these workarounds than that's cool, but be honest that's it's a workaround, a stop-gap to the lacking of Go's type system.

I disagree. Useful, proven abstractions like Futures, Map, Filter, Functors are actually simpler to use and reason about -- not more complex.

Using an acking system (like that in Storm or Heron) would move it to be physically at-least-once with a logical exactly-once by de-duping at the target.

This means if you observe the inner system, you won't be seeing exactly-once semantics but looking at the system from the outside, the semantics would indeed be exactly-once at the target.

But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. So you're not forced to store all the thread's stacks and you don't have expensive context switches.

As the parent illustrated, even with Go using nonblocking I/O, it's perceived benefits in that area isn't that great because Go still semantically has a thread-per-connection. So the performance characteristics of Go isn't simply async vs sync I/O.

There are a few different ways one could achieve this. The first options would be to generate a struct:

    struct RouteUser {
        route: &'static str,
        f: fn(_: &mut Request) -> PencilResult
    }

Then given

    #[route("/user")]
    fn user(_: &mut Request) -> PencilResult {}

You would hijack the `user` function to return an instance of the struct.

    fn user() -> RouteUser {
        // The actual function the user wrote:
        fn user(_: &mut Request) -> PencilResult {
            // ...
        }

        RouteUser {
            // Generated from the annotation argument
            route: "/user",
            f: user
        }
    }

There is a difference between item decorators (`#[foobar]`) and regular procedural macros and I'm not completely sure if you could in-fact significantly change the given function. I haven't touched procedural macros in a while.

To use the above route, you would simply have a `Route` trait perhaps.

    trait Route {}

And implement it for each generated struct:

    impl Route for RouteUser {}

Then you could use the route as

    app.route(user());

Which could be defined as

    fn route<R>(r: R) where R: Route {
        // ...
    }

There's probably some opportunity to use custom annotations in Rust to achieve the same thing.

    #[route("/foobar")]
    fn user(_: &mut Request) -> PencilResult {
        // ...
    }

However, procedural macros are unstable, but Rust is able to do amazing things with macros.

Will do, thanks!

Bay Area. Seems like there's a few choices with Hollister, Lodi, Monterey Bay, Norcal. Lodi seems like it's the bigger name out the bunch.

Tandem instructors at my dropzone did pretty much the same thing. All stayed on the GoPro 2 or original 3.

I used to jump at Eden North in Canada, but I'm moving to North California so I have to pick a new one :) Gotta love a Cessna Caravan going to 13K in under 9 minutes!

Even within GoPro's demographic of sports, everyone who wants one probably already has one, more or less. Upgrading is now less of a concern with 4K. I bought one for skydiving and I can't see myself upgrading if they came out with a newer version (even if I use mine for every jump). Everyone pretty much has one or a few GoPros at the dropzone's I've been to, and it's great for that kind of stuff. But if I were to upgrade, I would move to a DSLR for better quality and more control - not another GoPro.

They'd need to considerably improve the quality and features if they want people to continue upgrading.

I see their zero-rating as a much smaller issue than the data caps.

"It's ridiculous that in this day and age, people have to worry about their internet usage like it's some kind of limited resource."

The caps are driving additional zero-rating services.

He's not terrible, just a bit rough. I find his presentations far more appealing than any "perfect" presentation companies like Google, Apple or Facebook make.

He also doesn't fluff anything up or over sell anything. He tells the facts in a way people can understand and that's it.