Java JIT vs. Java AOT vs. Go for Small, Short-Lived Processes - <AUTHOR> http://macias.info/entry/201912201300_graal_aot.md <comment><AUTHOR> It's hard to square these articles with the reality I see on the ground: our baseline memory usage for common types of Java service is 1 GB, vs 50 MB for Go. We do have a few mammoth servers at the top end in both languages though (e.g. 75 GB heaps)

The deploy JARs have 100+ MB of class files, so perhaps it's a function of all the dependencies that you "need" for an enterprise Java program and not something more fundamental.

These blog posts also present AOT as if its just another option you can toggle, while my impression is that it's incompatible with common Java libraries and requires swapping / maintaining a parallel compiler in the build toolchain, configuring separate rules to build it AOT, etc. I don't have actual experience with it though so I could be missing something.

<comment><USER2> It's been the case ever since I can remember that "Java's basically as efficient as native, it's super fast" but all the actual java software I encounter is a slowish, bloated memory hog. I don't know why, but that's how it is.

<comment><USER3> The style of programming for the dominant JVM languages (Java, Scala, Kotlin) involves an over reliance on churning through a lot of short-term garbage. I think this partially due to how annoying the platform is to actually use. Incredibly complex and chalk full of programmer pitfalls (like type-erasure). In fact, the majority of devs have no clue at how the JVM works, treating it as just "magic."

I would imagine that Go's GC is worse than the tunable JVM ones, but go isn't powerful enough that one would ever be tempted to program in an abstraction heavy style. While I would argue it takes a lot more work to program in Go ca, day Scala, I think the constraints imposed lead to better software. I for one have never seen a JVM desktop or business app that worked super well. The JVM manages to be a highly optimized efficient platform in which almost exclusively slow, laggy, and memory hungry apps are produced. With that being said, it's a highly productive platform (if you're using something besides Java), especially for backend business apps.

<comment><USER4> GC is complicated because what works well for one thing might not work well for other things. GC can be both about clever things and about hard trade- offs. That said, I'll try to talk about GC without having a religious war erupt. Keep in mind, something here might be wrong.

Go's GC is tuned for low latency. People hate pause times. They hate it even more than they hate slowness. Go makes a trade-off for short pause times, but in doing so they do sacrifice throughput. That's great for a web server. With a web server, you care a lot about pauses offering a bad experience. A 500ms pause is going to give a customer a bad experience. That's less good for batch processing. Let's say you're running a backfill job that you expect to take 10-15 hours. You don't really care if it pauses for 1 minute to GC every 30 minutes. No one will even know. However, you will know whether it took 10 hours or 15 hours.

Go's GC is meant to be simple for users. I think the only option is "how much memory should I be targeting to use?" That makes it dead simple for users. I think the Go authors are right that too many tuning knobs can be a bad thing. People can spend months doing nonsense work. Worst is that knobs are hard to verify that anything is really different. If you're running a web server, was the traffic really the same? What about other things happening on the machine? Wouldn't you rather be writing software instead?

Go's GC is a non-copying GC. One thing this means is that Go's (heap) memory allocation ends up being very different because Go's memory is going to become fragmented. So Go needs to keep a map of free memory and allocations are a bit more expensive. Java (with GCs like G1) can just bump allocate which is insanely cheap. This is because Java is allocating everything contiguously so it just needs to move a pointer. How does that work once something becomes freed? Java's G1 (the default in the latest LTS Java) will copy everything that's still alive to a new portion of memory and the old portion is then just empty. You kind of see this in Go's culture. Web frameworks obsess about not making heap allocations. Libraries often have you pass in pointers to be filled in rather than returning something.

Go misses out on the generational hypothesis. The generational hypothesis is one of the more durable observations we have about programming - that most things that are allocated die really quickly. C# and Java both use generational collectors by default and they've done way better than what came before. C# and Java don't have as-low pause times as Go, but part of that is that they're targeting other things like throughput or heap overhead more.

Go doesn't need GC as much. Go can allocate more on the stack than Java can and, well, Go programmers are sometimes a bit obsessed with stack allocations even when it makes for more complicated code. Having structs means creating something where you can just have contiguous memory rather than allocating separate things for the fields in your object. Go's authors have observed that a lot of their objects that die-young are stack allocated and so while the generational hypothesis holds, it's a bit different. Go has put a good amount of effort into escape analysis to get more stuff stack allocated.

Java has two new algorithms ZGC and Shenandoah which are available in the latest Java. They're pretty impressive and usually get down to sub-millisecond pause times and even 99th percentile pauses of 1-2ms.

Go's new GC was constrained by the fact that "Go also desperately needed short term success in 2015" (Rick Hudson from Google's Go team) and the fact that they wanted their foreign function interface to be simple - if you don't move objects in memory, you don't have to worry about dealing with the indirection you'd need between C/C++ expecting them to be in one place and Go moving them around. Google's going to have a lot of code they want to use without replacing it with Go code and so C/C++ interop is going to be huge in terms of their internal goals (and in terms of what the team targeted regardless of whether it's useful to you). And I think once they had shown off sub- millisecond pause times, they were really hesitant to do something that might introduce things like 5ms pause times. I think they might have also said that Google had an obsession with the long-tail at the time. Especially at Google, there's going to be a very long tail and if that's what people are all talking about and caring about, you end up wanting to target that.

Go has tried other algorithms. They had a request-oriented-collector and that worked well, but it slowed down certain applications that Go programmers care about - namely, the compiler. They tried a non-copying generational GC, but didn't have a lot of success there.

Ultimately, Go wanted fast success and to solve the #1 complaint people had: extreme pause times (pause times that would make JVM developers feel sorry for Go programmers). Going with a copying GC might have offered better performance, but would have meant a lot more work. And Go gets away with some things because more stuff gets stack allocated and Go programmers try to avoid heap allocations which would be more expensive given Go's choices (programming for the GC algorithm).

I don't think that JVM languages have a programming style that lends themselves to an over-reliance on churning through short-term garbage. Well, Clojure probably since I think it does go for the functional/immutable allocate-a-lot style. Maybe Kotlin and Scala if you're creating lots of immutable stuff just to re-allocate/copy when you want to change one field. That doesn't really apply to most Java programs. And I have covered the way that Go potentially leads to more stack allocations. However, I don't think most people know how their Go programs work any more than their JVM programs and this really just seems to be a "I want to dislike Java" kind of thing rather than something about memory.

Java programs tend to start slow because of the JVM and JIT compilation. Java has been focused on throughput more than Go has (at the expense of responsiveness). That is changing with the two latest Java GC algorithms (and even G1 which is really good). Java is also working on modularizing itself so that you won't bring along as much of what you don't need (Jigsaw) and AOT compilation. Saying that Java is slow just isn't really true, but it might feel true - things like startup times and pause times can inform our opinions a lot. There's absolutely no question that Java is a lot faster than Python, but Python can feel faster for simple programs that aren't doing a lot (or are just small amounts of Python doing most of the heavy work in C).

I mean, are you including Android in "all Java apps"?

Java, C#, and Go are all really wonderful languages/platforms (including things hosted on them like Kotlin). They're all around the same performance, but they do have some differences. I think Go should re-visit their GC decisions in the future, especially as ZGC and Shenandoah take shape, but their GC works pretty well. But there are certainly trade-offs being made (and it isn't around language features that make the platform productive for programmers). I think GC is very interesting, but ultimately Java, C#, and Go all have very good GC that offers a good experience.

<comment><USER5> Java is slower than Python for simple short-running programs. When Python is finished Java is still struggling through start-up and class-loading.

<comment><USER6> Is this actually true? Have you measured this, or seen measurements?

<comment><USER5> Here are measurements for an extreme case of a short-running simple program:

      $ cat Hello.java
      class Hello { public static void main(String[] args) { System.out.println("Hello from Java!"); } }

      $ cat hello.py
      print("Hello from Python!")

      $ time /usr/lib/jvm/java-13-openjdk/bin/java -Xshare:on -XX:+TieredCompilation -XX:TieredStopAtLevel=1 Hello
      Hello from Java!

      real 0m0.102s
      user 0m0.095s
      sys 0m0.025s

      $ time python3 -S hello.py
      Hello from Python!

      real 0m0.034s
      user 0m0.020s
      sys 0m0.013s

It's a bit faster if you create a custom modular JRE with jlink:

      $ /usr/lib/jvm/java-13-openjdk/bin/jlink --add-modules java.base --output /tmp/jlinked-java13-jre
      $ /tmp/jlinked-java13-jre/bin/java -Xshare:dump
      $ time /tmp/jlinked-java13-jre/bin/java -Xshare:on -XX:+TieredCompilation -XX:TieredStopAtLevel=1 Hello
      Hello from Java!

      real 0m0.087s
      user 0m0.050s
      sys 0m0.035s

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Go has no proper solution to garbage collector ballast, a hack which businesses you've heard of are using in the wild. see [https://blog.twitch.tv/en/2019/04/10/go-memory-ballast- how-i...](https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt- to-stop-worrying-and-love-the-heap-26c2462549a2/) and [https://github.com/golang/go/issues/23044](https://github.com/golang/go/issues/23044). A golang team member's reasons for not adding a minimum heap size include that it would require more testing each release, and that they might want to have a max heap size hint instead.

I posted a comment similar to this one recently, but it seems more relevant here.

<comment><USER8> I've noticed similar things while profiling my tests - making a large static allocation or bumping GOGC=1000 can cause them to run more than 2x faster (my favorite took a 12 second test suite and dropped it to about 2.5 seconds). So much time is spent assisting the GC to keep memory at like an 8-12mb range, as if that small of a heap was somehow the most important thing Go could be doing with the CPU.

</comment></comment><comment><USER9> For a short lived Java process you can use the no-op garbage collector (ie don't collect). [http://openjdk.java.net/jeps/318](http://openjdk.java.net/jeps/318)

<comment><USER10> That would save the trouble of initializing a garbage collector that isn't going to be used. Is that a significant saving?

<comment><USER11> _"Last-drop throughput improvements. Even for non-allocating workloads, the choice of GC means choosing the set of GC barriers that the workload has to use, even if no GC cycle actually happens. All OpenJDK GCs are generational (with the notable exceptions of non-mainline Shenandoah and ZGC), and they emit at least one reference write barrier. Avoiding this barrier can bring the last bit of throughput improvement. There are locality caveats to this, see below."_

From: [https://openjdk.java.net/jeps/318](https://openjdk.java.net/jeps/318)

<comment><USER10> I'd missed that, thanks.

</comment></comment></comment></comment><comment><USER12> When I was looking for my first car in early 90s, I knew nothing about cars or brands. One thing I noticed was that all the TV ads for most of the cars would say "more room than a Camry". I knew what I needed to buy.

If Go doesn't survive another decade, I would still be happy about what it triggered.

</comment><comment><USER13> 100 ms is nowhere near what I'd call "negligible" for a process that might only live a second or two!

python -c print 'hello' starts up and shuts down an entire Python interpreter in less than 50 ms on my machine, whereas the equivalent Java program never takes less than 120 ms. That seems pretty sad for a language that's had at least an order of magnitude more resources thrown at it.

<comment><USER14> > whereas the equivalent Java program never takes less than 120 ms

Then you must be using an old version of Java.

<comment><USER8> Given that hardware varies, and the article was showing 80-90ms floors: 120ms floor seems entirely reasonable to me.

<comment><USER14> The article wasn't using a current Java, either. Current numbers are under 40ms for Hello, World: [https://cl4es.github.io/2019/11/20/OpenJDK-Startup- Update.ht...](https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.html)

<comment><USER5> That's certainly good news and the renewed focus on start-up performance is very welcome. I wonder what the numbers look like for small Kotlin programs.

(Although I see now that the comparison disabled CDS on Java 8, so the actual improvement is perhaps not as large as it seemed.)

</comment></comment></comment></comment></comment><comment><USER15> I'm curious how Dart2Native would fare in this test, if it would be more or less the same as Go or if it would be more efficient.

<comment><USER16> I'm curious about this too. Dart has an interesting runtime since it supports both quick JIT compilation and AOT to machine code.

<comment><USER15> With Flutter it's fully AOT compiled to binary ARM code and is a compelling choice for IoT applications as well.

</comment></comment></comment><comment><USER17> I've run small services built with Java, Go and Crystal to achieve good startup and throughput performance while minimizing memory usage. My experience with Crystal is limited but has been positive thus far.

The sweet spot for me is using Java with OpenJ9 which has very fast startup time while sacrificing only a bit of top-end throughput.

I would only choose AOT if packaging/deployment were issues with the JIT approach. In the case of Go, AOT is practically free but I prefer not being limited to array/slice, map, and channel generics.

</comment><comment><USER18> I'd kill for a comparison with the IBM J9 AOT flag. It essentially just caches jitted code for startup. Also if startup time is super important than you can try -Xquickstart.

</comment><comment><USER19> Interesting numbers. I have been out of the Java world for a few years and I'm unfamiliar with GraalVM but I'm curious how compatible it is with Oracle Java or OpenJDK.

Of course for small scale stuff like a QuickSort implementation, JVM starts are fast-ish, but for a nontrivial service, library load times during boot can balloon quickly depending on your build discipline.

<comment><USER20> incredibly compatible, albeit with some limitations. The compiler is quite aggressive, so e.g. you can't do reflection on "any" class, you just have to tell the compiler what you are going to use at runtime (so called "closed- world assumption"). Also most initialization code is forced to run at "compile-time" to keep boot time low. Pretty incredible piece of code.

<comment><USER21> What's the license on it?

I'm looking at a project that makes " _The main benefits of doing so is to enable polyglot applications (e.g., use Java, R, or Python libraries)_ " sound attractive.

</comment></comment></comment><comment><USER22> This article reiterates the belief that jvm start-up time is slow is somewhat a myth. When. I measured it years ago, I found jvm start-up time to be roughly equivalent to node.js.

What makes start-up time bad in any interpreted language, including Java, python, and JavaScript, is code-loading time. This time is 0(n), where n is the total size of your app, including transitive dependencies. It takes time to load, parse, and validate non-native code. This time far dwarfs any vm start-up time.

As an experiment, write a hello world node.js app and time it's execution. Then add an import statement on the aws sdk. Don't actually use it. Just import it! When I last measured it, this caused start-up time to go from 30 Ms to something like 300 Ms. The extra time mostly comes from loading code.

For a native app, the binary itself just gets mmapped into memory. Shared library loading is more expensive, but not much, and way less than loading source code or byte code.

The tldr is if you want a fast starting non-native app, you have to shrink the transitive dependency closure your app loads to do it's job. This is easy for toy benchmark apps but can be harder for real apps. It also goes against the philosophy of most devs to rely on third party libraries for everything. For instance, If you care about start-up time, it may be worth re implementing that function you'd normally get from guava or apache commons. You can alternatively use a tool like proguard to shrink your dependency closure.

</comment><comment><USER23> It would be nice to have some automated tools to convert from Java to Go or Rust. Something like c2rust [1], but for Java. There exist[2] some kind of automation, buts it's too basic to be practical.

[1] [https://GitHub.com/immunant/c2rust](https://GitHub.com/immunant/c2rust)

[2] [https://github.com/aschoerk/converter- page](https://github.com/aschoerk/converter-page)

</comment><comment><USER24> "3 Bad Tools for a Job, which is least bad?"

<comment><USER25> This.

With a big enough hammer, every screw is a nail.

</comment></comment><comment><USER26> Why can't the JVM preload on startup the majority of the core runtime as a shared library architecture in a sort of super-permanent generation, and then the JVMs piggyback on that?

I remember solaris boxes had little of the startup cost and someone told me they preloaded the java runtime.

<comment><USER27> It does. That's called AppCDS and is a relatively recent feature, it's also not on by default buy they're working on making it be used automatically.

</comment></comment><comment><USER28> Wouldn't the JIT:ed code be optimized for the specific CPU, whereas the AOT perhaps can not make use of certain instructions? Also, when making a comparison off the different models one must keep in mind that the software that processes the code have different characteristics.

<comment><USER4> JIT'd code isn't just about specific CPUs, but about optimizing hot paths. For example, you don't want to inline a commonly used function all over the place, but if there's one area that calls it 10,000 times per second while the others call it once a minute at most, you can re-write the program at runtime having observed that hot code path.

To get an intuition for JITs: there are pieces of your code that you know will always be run in a certain way (or mostly run in that way), but it isn't provable at compile time that it will always be that way. JITs can notice that pattern and optimize it (or even provide optimizations for common, but not exclusive paths).

<comment><USER25> While they could, in principle, do this, does anybody actually do it in production?

<comment><USER29> Yes, if you have Java code that runs for more than a few minutes in production.

</comment></comment></comment></comment><comment><USER30> Interesting write-up - would be nice to see not just the quicksort code, but the harness/scripts used for benchmarking. As far as I can tell it's not included?

</comment><comment><USER31> I wonder if AOT would speed up Groovy as well. My intuition is that it doesn't matter, since the runtime will get bundled and execution time will be the same.

<comment><USER32> That's exactly what happens. When you compile Groovy with GraalVM it will generate a fallback image that still requires a full JVM.

</comment></comment><comment><USER33> Since the article is about "short lived processes", I'm having a hard time caring about the memory use as a first order issue. <shrug>

<comment><USER34> Depends on how many of them you have running at any one instant.

<comment><USER35> If you have short-lived tasks popping off at that rate, the JVM looks some orders of magnitude better if you don't spin up a fresh process for every task.

</comment></comment></comment><comment><USER36> The question is: if you compile Java to native code, what's the purpose of using Java instead of Go or Rust or C++?

<comment><USER37> Existing code.

Existing expertise.

Existing tooling.

<comment><USER23> You can convert it to Kotlin and just use LLVM-based native[1] compilation that is even more complex efficient. It's completely automated, and gives you the better and more modern language without much hassle.

[1] [https://kotlinlang.org/docs/reference/native- overview.html](https://kotlinlang.org/docs/reference/native-overview.html)

<comment><USER38> Except it barely has a stdlib without the JVM. You cant even read a file in knative without having to do a posix syscall.

</comment></comment></comment></comment><comment><USER39> For anyone looking to avoid attacks because of no SSL: [https://archive.is/Rzdko](https://archive.is/Rzdko)</comment>


Microservices, the Unix Philosophy, and the Richardson Maturity Model - <AUTHOR> https://medium.com/@chrstphrhrt/microservices-the-unix-philosophy-and-the-richardson-maturity-model-425abed44826 <comment><USER2> Any microservices discussion that does not take into account both infrastructure complexity and team size is incomplete. For small teams and small/not complex infrastructures, it's always a bad idea. The premium that is paid for switching to microservices is great indeed and it's paid in __much __slower development and deployment times. This happens as soon as you start breaking an application apart, so even with only a couple of "mini" services, much of the price has been paid.

Since the author doesn't mention either, I can't conclude anything, but it's very possible that the team he was advising didn't follow his advice because it was stupid and didn't take into account the above two factors.

See obligatory reading:

[http://martinfowler.com/bliki/MonolithFirst.html](http://martinfowler.com/bliki/MonolithFirst.html)

[http://martinfowler.com/bliki/MicroservicePremium.html](http://martinfowler.com/bliki/MicroservicePremium.html)

EDIT: Spacing

<comment><USER3> The part I love about microservices, and something that I think doesn't get enough attention, is that is strongly enforces separation of concerns across micro-projects. API boundaries are very clear and very rigid, it takes very little effort or oversight to prevent leaking across them. Essentially, you are moving some of the software 'best-practices' up a level form modules to applications themselves. This means that you don't need to spend a lot of effort writing great, best-practices following, future-proof, software upfront for fear of collecting horrible technical debt down the road. Got a service that was rushed out the door and isn't maintainable anymore? Rewrite it! 2 weeks later you have erased a bunch of technical debt and since you kept the same API(s) in place, you have not affected the rest of the services that make up your application.

And that is the other thing that I think microservices are great at: They are pragmatically easier to change. Delving into a huge, old, debt-riddled monolithic codebase to make changes is hard and scary, and developers are less likely to want to make changes to monoliths because of that. Microservices are easy to understand because they are small, discrete systems with well understood interface contracts. Making changes to them without breaking the entire app is not scary because it is easier to throughly understand the implications of what is being changed.

<comment><USER4> I'm sort of playing devil's advocate here, but:

> Got a service that was rushed out the door and isn't maintainable anymore? > Rewrite it! 2 weeks later you have erased a bunch of technical debt and > since you kept the same API(s) in place, you have not affected the rest of > the services that make up your application.

But that's also true of a monolith. Got a piece of your system that isn't maintainable any more. Rewrite it! 2 weeks later you have erased... you get the point.

I like the idea of microservices. I like the idea of the clean boundaries. As a developer, the separation seems correct to me. But, unless you're actually feeling the pain point of the monolith, it just seems like more work that falls into the category of YAGNI.

You also said this:

> Delving into a huge, old, debt-riddled monolithic codebase to make changes > is hard and scary...

I mean, it's hard and scary if you don't have a high level of test coverage. If you have great coverage in the old monolith, you should be able to change pieces of it with confidence, no?

<comment><USER3> Yes, you can always rewrite parts of a monolith, what I am saying is that it is just way easier to do with the hard-boundaries and well-defined interface contracts of microservices. You know that as long as you live up to the interface contracts, any changes you make to the microservice app cannot adversely affect other microservices. Just think about how much of software development patterns and best practices are devoted to creating proper encapsulation and avoiding tight coupling; All of that is simply built-in when you use microservics.

Yes, of course if you have great test coverage making changes to a monolith can be easier, but good test coverage and debt-riddled don't often apply to the same codebase! Lets be honest, if you are happy with your monolith codebase then there is no reason to rewrite for microservices. It is for those projects that you are not happy with the monolith code, where maintenance of the code IS scary, that the conversion makes sense.

</comment></comment></comment></comment><comment><USER5> Can anyone add practical experience with the API spec tools. This is a new name for me.

I had a look at the websites for each of the three tools the article specifically mentions

        http://raml.org/
        http://swagger.io/
        https://apiblueprint.org/

I get the impression that these are code generating tools built from a specification file.

I have real world experience with two tools which fit that rough description. SOAP and google app-engine end-points.

I would unambiguously describe both as awful. Really horrible experiences with both. They tie your systems to large, and difficult to understand tool sets. SOAP wasn't obviously buggy, but app engine endpoints are unpredictable and the generated code produces some serious awkwardness.

I don't want to slap a label on these tools and dismiss them off-hand.

Anyone used them 'for the win'?

<comment><USER6> We've tried various ad-hoc approaches to documenting our APIs in the past.

When we switched to RAML (and json schema) for our API definitions, everything got a lot better.

RAML defines the resources (uris, parameters, media types, etc.) while json schema is used for more detailed information (what's the exact structure of the application/json response to a call to GET /jobs).

While there are theoretical gains in generating code from the RAML, we don't seek these out as its no big deal to hand-code Spring controllers, even a lot of them.

The real value for us is in having a single, well-documented source of truth about our APIs. Customers using the APIs, developers implementing them, testers testing them, trainers learning about them, all go to one place.

And RAML has some handy tools (like raml2html) to create human-readable documentation from the RAML.

We've also added our own tools to parse sample json responses against the json schema which have greatly aided us in finding discrepancies.

In short something like RAML (or probably blueprint or swagger too) is, I feel, essential if you have a lot of APIs and a lot of people, and if you have aspirations of an increasingly automated toolchain.

FWIW, there's a line of thought that RAML is at odds with hypermedia and HATEOAS. After all, why would anyone need a detailed API document, when clients should be getting information from the hypermedia responses of previous API calls? I don't agree with that, even if just because internally your development team still needs to build out all those APIs.

</comment></comment><comment><USER7> OT: More than 10 years ago, Jim Waldo [1] gave a great talk on SOA. I remember listening to an MP3 version of it then. I could find many references to the talk online now (eg [2]), but talk itself seems to have vanished off the web. Does anyone have the MP3 of the talk?

[1]: [http://www.eecs.harvard.edu/~waldo/](http://www.eecs.harvard.edu/~waldo/) . Also see a great paper he co-authored at [http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf](http://www.eecs.harvard.edu/~waldo/Readings/waldo-94.pdf)

[2]: [http://www.gettingagile.com/2005/09/17/jim-waldos-talk-on- so...](http://www.gettingagile.com/2005/09/17/jim-waldos-talk-on-soa/)

<comment><USER7> Here are the slides: [https://web.archive.org/web/20051029050650/http://www.jini.o...](https://web.archive.org/web/20051029050650/http://www.jini.org/events/0505NYSIG/WaldoNYCJUG.pdf)

</comment></comment><comment><USER8> _Becoming encumbered by a monolithic centralized API that is at risk of reaching its maximum performance and hosting limits._

Comically wrong. You can just fire up more instances (aka horizontal scaling).

Microservices have their merits, but they're often the (misguided) Dev answer to Ops problems.

<comment><USER9> > _You can just fire up more instances (aka horizontal scaling)._

(sigh) I wish that were always doable.

<comment><USER8> Obviously no technology will give you infinite horizontal scaling for any sufficiently complex app.

There is more than one way to achieve scalability. Microservices is just one of the possible choices. It annoys me that developers increasingly see it as the only one.

<comment><USER10> There is more than one way to achieve scalability, but as far as I'm aware all of them beyond something more beyond _just_ firing up more instances.

<comment><USER8> Designing an infrastructure which allows you to solve problems by firing up more instances is non-trivial work, beyond the skillset of many (otherwise apt) developers.

<comment><USER10> I'm not sure I disagree; but that seems to precisely refute your initial, bold claim in this thread.

<comment><USER8> My original wording was too concise, sorry.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I like stuff like TFA that pulls in concepts from numerous sources even if all the pieces don't fit together perfectly. For instance, I doubt Leonard Richardson would be thrilled with the " _Ramses_ Maturity Model" (we couldn't even coin a different initialism?) and the "Level 2.5" idea. Eschewing links runs counter to Richardson's (and Fielding's) vision, period. If one must know the form of representations ahead of time, one cannot consume them in a completely maintainable way. One wouldn't notice this within the organization, but rather at the edges where it must work with other organizations.

That said, Ramses and what it's described as doing is impressive.

<comment><USER12> Thanks for the great feedback, you're completely right. I have switched up the language a bit.

Regarding hypermedia: I really, really want to work with someone to add first class support for it. I don't think spec is a replacement but rather a compliment to hypermedia. The difference in benefit seeming to be static vs. dynamic client generation and I fully agree that dynamic ought to be the future. Right now static is easy to implement and still quite powerful despite requiring tradeoffs about things like needing to version releases of client libs rather than them being more durable in the dynamic scenario.

</comment></comment><comment><USER13> > Then there's Level 3. It adds hypermedia links to the mix so that clients > can dynamically browse resources à la HTML in a browser. This is where > Ramses departs from all the awesome work that's being done in the world of > hypermedia.

This is the good ol' HATEOAS principle of REST: [http://stackoverflow.com/a/9194545/449288](http://stackoverflow.com/a/9194545/449288)</comment>


Finding a CPU Design Bug in the Xbox 360 - <AUTHOR> https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/ <comment><USER2> I'm now wondering if I have enough material to do an interesting writeup for my time as a CPU bug-hunter in verification.

The client (a now vanished startup) had a small 8-bit CPU design which they wanted validation for, using the technique of executing random sequences of instructions and comparing the result against an emulator. We wrote the emulator independently from their architecture description. Given that most instructions were a single byte plus arguments and most of those were valid, the test coverage was pretty thorough. All looked fine until I added support for interrupts, at which point we discovered that an interrupt during a branch would not return to the correct point in execution.

Verifying security properties of processors is _really hard_ ; you can go looking for specific types of failure, but I'm not aware of a general way of proving no information leakage.

<comment><USER3> > but I'm not aware of a general way of proving no information leakage.

As I understand it, the current consensus is to use a tagged architecture, then show that there are no observable differences when the tags involve secret data and the value of the tagged data changes.

There are a few rubs here. One is that this is pretty hard to do. The other is that no one wants to pay the overhead of using a tagged architecture. Yet another is that deciding what "observable difference" means is challenging (too little, and you probably miss attacks, too much, and you will probably discover information leaks).

Further, this kind of rigorous system hasn't been rigorously empirically evaluated by a third party (as far as I know, perhaps in part because it's so hard to create these systems). "Empirically evaluated?" you scoff, "there's a proof, what's the point of testing?" Well...

For a glimpse of what this looks like, consider the SAFE architecture: [http://www.crash-safe.org/assets/verified-ifc-long- draft-201...](http://www.crash-safe.org/assets/verified-ifc-long- draft-2013-11-10.pdf) and lowRISC: [http://www.lowrisc.org/downloads/lowRISC- memo-2014-001.pdf](http://www.lowrisc.org/downloads/lowRISC-memo-2014-001.pdf)

<comment><USER4> Overhead of tagged architecture is to some extent an myth caused by abysmal performance of certain implementations (eg. iAPX whose performance problems are AFAIK caused mainly by funky instruction encoding) and by performance issues with "straightforward" way of running C code on such architectures.

</comment></comment></comment><comment><USER5> Article Excerpt: "So a speculatively-executed xdcbt was identical to a real xdcbt!"

I've never thought about it until I saw the above line in the article, and that thought went something like this:

"Assembler instructions which might never have the conditions met for their execution during a program's runtime might be speculatively executed nonetheless, and this, depending on the nature of the instruction executed, might have huge ramifications up to and including program incorrectness and even program failure."

In other words, your absolutely 100% deterministic Turing machine (or programs that you write on it that you deem to be 100% deterministic) -- may not be quite so deterministic when viewed against these understandings...

It adds a whole new dimension to what must be thought about when writing assembler code...

Anyway, it's a really great article!

<comment><USER6> The machine is still deterministic, it just doesn't conform to the assumption. It's a bug. You can only think about the bug when you write the assembly code if you know about it.

There is lots of hardware with strange bugs out there, and in some setups (embedded devices, mission critical systems etc.) it can be easier to work around them instead of trying to fix the hardware. I know of a medical systems manufacturer which still sticks to some incredibly old CPUs, a home-grown operating system and gcc 2.95 because after 15 years they think they at least know about all the problems and how to work around them. Fixing the issues would pretty much require them to re-validate the whole design and repeat all the testing, which would take several years.

<comment><USER7> In production though the machine will not behave deterministically from your perspective, because you do not have all the inputs to the machine. Some of the inputs are controlled by a third party (the hypervisor, or worse, another VM running on your EC2 host that is actively manipulating branch predictor data to control the speculative execution for your application.) Even if you capture every operation that runs inside your VM, including register states, timing, etc, you won't be able to reproduce the actual behavior that occurred on the host because you don't know what happened outside the VM.

One could argue that the introduction of cloud computing (using virtualization) has converted the machines we run on from deterministic to sorta-deterministic. It just happens that until now we haven't been hurt by it much. Now everyone's paying for it, to the tune of a sizable performance hit on syscalls.

<comment><USER8> A medical company using old processors and gcc2 for their system is not running on AWS.

But still no. Deterministic means the the input maps consistently to the output. The hardware in this sense is doing the mapping. Deterministic does not mean for all x the only mapping is f(x). It means when f(x) is the mapping f(x) does not change to f'(x). However g(x) is a perfectly deterministic possibility for a mapping too. Point being two hardwares f(x) and g(x) can independently deterministically map x. The existence of two hardwares does not affect whether it's possible to deterministically map x or not. The reality and I think your point is that if you are unaware a different hardware is performing the mapping this can lead to a result that would appear nondeterministic. But the original point with the medical company anecdote is that this is only an appearance and in some domains people go to great lengths to make sure they intimately understand their f(x) and make sure they're not using a g(x) they don't understand.

<comment><USER9> In fact, they aren't running anything they don't know about.

</comment></comment></comment></comment></comment><comment><USER10> Awesome story! I'm curious though why the branch predictor was running the xdcbt instruction if "The symptoms were identical. Except that the game was no longer using the xdcbt instruction".

Was the game no longer "using the xdcbt instruction", but the branch predictor caused issues, because they put a jmp instruction in front of it instead of removing the instruction entirely?

<comment><USER11> As I understand it, the function that used the xdcbt instruction had an oversight that led to the first set of crashes, so it was rewritten to fix that issue. Even with the fix, the game programmer decided to remove the PREFETCH_EX flag, which is what caused the copy routine to use xdcbt in the first place. So xdcbt ended up in the compiled code, but the flag that caused it to be used wasn't there. The branch predictor ran it anyway, in an unsafe way, leading to the next set of crashes.

<comment><USER12> I think that the developer didn't yet have the fixed version. They thought they would be safe because they weren't passing PREFETCH_EX, but the branch predictor decided otherwise.

There were other ways that xdcbt could cause problems (what if the block of memory was freed before being purged from L1) so who knows, and I don't remember for sure.

<comment><USER13> I'm going to assume that somewhere in the code was something like

       if(flags | PREFETCH_EX)
       {
         xdcbt
       }
       else
       {
         safe way
       }

And the branch predictor would decide the xdcbt branch was most likely, executes xdcbt and then realizes oops and does it the safe way. Which would be okay except xdcbt is evil, it breaks cache coherency.

<comment><USER14> Wow, interesting to see feature flags causing this undesired effect!

<comment><USER15> Any if statement could cause this, doesn't have to be feature flags.

An untrained branch predictor could still take the "wrong" path even if none of the code that calls that if statement takes the bad path. That's presumably what happened here, the calling program removed all instances of PREFETCH_EX but the CPU would still sometimes execute that branch, such as on the first run through that function.

This is a lot like the problem of "don't think of a pink elephant". The mere existence of the "evil opcode" in the library means the CPU might execute it under certain circumstances.

</comment></comment></comment></comment></comment></comment><comment><USER16> Would it be fair to say that having any sequence of bytes in memory which looks like the _xdcbt_ instruction (even if those bytes are just data) is unsafe? Given that a stale entry in the branch prediction table might end up pointing at those bytes.

<comment><USER17> Data and code are not quite so interchangeable (thankfully). Typically programs have code segments and data segments, and processors actually have support for specifying the difference in behavior. A branch predictor would probably not run against pointers to memory segments without the execute bit set.

<comment><USER18> Actually, this is exactly the assumption that led to the Meltdown bug. The Intel CPU speculative (non-retired) instruction pipeline runs instructions which access memory and load it into cache and execute the instructions, delaying the check that the memory is accessible within the current context until later (just before instruction retirement).

It's certainly possible that a CPU could delay the same sort of exception processing for "NX" flags until later in the pipeline, but still before retirement, allowing a similar sort of problem as Meltdown.

</comment></comment></comment><comment><USER19> This issue that xdcbt is supposed to solve happens at a completely different level. Performing a full disk to tape backup would slow systems down because the entire disk would be copied through the OS buffer cache, evicting data used by other processes.

The UNIX fix for this was to use a raw device or O_DIRECT to bypass the buffer cache.

Maybe Intel's new cache partitioning feature offers a similar fix, see:

[https://lwn.net/Articles/694800/](https://lwn.net/Articles/694800/)

Actually in the comments someone mentions using cache partitioning for security. Maybe the threads used by jit code could be placed in their cache partition to avoid some of Spectre.

</comment><comment><USER20> Correct me if I'm wrong, but won't Meltdown/Spectre bug allow people to jailbreak pretty much any os/device that has CPU that "supports" these bugs? This could potentially open a lot of currently closed devices to people.

<comment> Const-me Potentially.

The problem with X360 is it can't run arbitrary native code, it only can run code digitally signed by MS. The hypervisor refuses to run an unsigned code, and the key never leaves the CPU i.e. very hard to tamper with.

X360 can execute JavaScript in the web browser, and .NET in (now discontinued?) XNA. I'm not sure if it's possible to exploit the bug if you can only run JavaScript or .NET, both are very high level and have strong security model on top of what's in the hardware/OS/hypervisor.

<comment><USER21> Surely they use asymmetric crypto, so the private key needed to sign code isn't present on the console at all?

Spectre might make it possible to dump the public keys but they're not very useful to us.

</comment></comment></comment><comment><USER22> I have seen _so many_ bugs and crashes created exactly because of this kind of thinking:

> [insert X here] was no longer guaranteed, but hey, we're video game > programmers, we know what we're doing, it will be fine.

<comment><USER2> The games industry pretty much valorises doing weird things with the hardware, all the way since the Atari 2600 through the demoscene.

</comment></comment><comment><USER23> Reading about the architecture of that chip (3 core, PowerPC) I am amazed at how smooth GTA V could run on it.

</comment><comment><USER24> Where are the L1 caches?

<comment><USER25> I believe each core had its own L1 cache, hence why it's not possible to see on the diagram.

<comment><USER12> I think the L1 caches are the per-core blue blobs visible in this die shot:

[https://randomascii.files.wordpress.com/2018/01/xbox360_proc...](https://randomascii.files.wordpress.com/2018/01/xbox360_processor_die- fixed.jpg)

but I'm not sure.

<comment><USER26> Is there a way to "recognize" this? For example why the blue blobs and not the green ones?

<comment><USER27> Cache/RAM always looks like basically solid colors because it's so densely packed with a repeating structure.

How would you know it's not the green stuff? I don't know, perhaps by size. I would imagine the green stuff is some other kind of cache or memory (op cache? TLB buffers? patchy SRAM).

This is what I know from seeing these shots online for years. I'm no expert by any means.

<comment><USER12> The green stuff might have been the VMX register files - those things were pretty huge (128 registers per thread, each register 16 bytes, so 2 _128_ 16=4 KiB per core). While the L1 cache was higher capacity (32 KiB) as a general rule of thumb faster memory uses more die area per bit.

But I seem to remember being told that the green areas were the VMX pipelines. I don't remember clearly, and the hardware people I asked at the time were uncertain - they were too far removed from that aspect of the hardware.

The other reason to assume that the blue is the caches is because it is closer to the cross-bar and the cross-bar is what connects the cores to the L2. Incoming data from the L2 goes first to the L1 caches so they would logically be on that side.

</comment></comment></comment></comment></comment></comment><comment><USER28> Great read!

</comment><comment><USER29> Would gcc's "__builtin_expect" construct help in these cases?

<comment><USER30> In general, no, because branch predictors often ignore or override hints like this. It's hard to say without knowing this architecture specifically, of course.

Keep in mind that it's possible for a branch predictor to predict with "high confidence" a branch it's never seen before, because many branches may overlap into the same memory region of the predictor. The article touches on this.

</comment></comment><comment><USER31> Very well written. Thanks for sharing!

</comment><comment><USER32> _Scratches PowerPC off the list of trustworthy CPUs_

Sooo, out you go, G5. Any suggestions what to use for online banking? A 486 can't handle all the jQuery and tracking scripts.

<comment><USER33> In the list of possible risks to online banking (and why is it always online banking in these hypothetical world-is-ending scenarios?), CPU bugs are way down the list.

<comment><USER34> It's the stereotypical "why to use SSL" that everyone thinks of first.</comment></comment></comment>


The US economy has come to a standstill, satellite imagery shows - <AUTHOR> https://www.cnbc.com/2020/03/28/the-us-economy-has-come-to-a-standstill-satellite-imagery-shows.html <comment><USER2> Curious how long this condition will persist with a grand total of zero celebrity deaths worldwide and a relatively modest amount of deaths made up primarily of people either elderly or suffering from comorbidities?

Meanwhile in just a few months (Oct 1, 2019 - Mar 21, 2020) the common flu has quietly killed between 24,000-64,000 Americans. [https://www.cdc.gov/flu/about/burden/preliminary-in- season-e...](https://www.cdc.gov/flu/about/burden/preliminary-in-season- estimates.htm)

</comment><comment><USER3> What does satellite imagery say about China ?</comment>


Why the @*$% does this code exist? - <AUTHOR> https://github.com/HeySquirrel/tribe <comment><USER2> Where the @*$% has this been all my life ??</comment>


New Features in C# 6 (2014) - <AUTHOR> http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-features-in-c-6.aspx

<comment><USER2> > We'd somehow convinced ourselves that it wasn't possible to implement, but > now we've figured it out, so apparently it wasn't impossible after all.

I love the human style Microsoft has taken on in the past few years.

<comment><USER3> Interestingly, the feature they said that about (async rewriting in catch/finally blocks) is almost exactly the feature that has been floating around the clojure-sphere as an example of something tremendously complex that was made easier by being more imperative. It's hard to explain how much of a rat's nest something can be without being trapped in it yourself, but "people thought it was impossible to do _at all_, and we were doing it in a purely functional way until we refactored" sounds pretty nuts.

<comment><USER4> async in a catch/finally is exactly the feature I'm looking forward to most - specifically the ability to define what to do in a failure situation in a concise asynchronous fashion without having to fall back to callbacks or spinning up a background thread.

</comment></comment></comment><comment><USER5> I love all the little space saving features C# has been adding. Null checking is something that every developer has to do constantly, making it a one character thing is super cool, while still maintaining readability.

Lambdas, null conditionals, LINQ, compile-time generics, etc, none of these features on their own are all that amazing, but when you add them all up it just makes for a more pleasant experience.

Most of my time is spent in Java, building an Android app right now, and C#, building services, and I constantly feel like I'm doing battle with Java's syntax (it's interesting to me that the new Android Studio compresses lambda- like classes, like runnable, to look like lambdas).

<comment><USER6> I would say that both LINQ and lambas _are_ amazing on their own (and even better together). Both of these completely change how you write code and makes it much more compact and readable

<comment><USER7> I feel a little disappointed by LINQ. On the one hand, it is an awesome feature. On the other, I feel there is a more general theory of what LINQ does that could have been integrated into the language core, and then it wouldn't be necessary.

In other words, LINQ should have been a library, not a language feature. (In my ideal world. It is possible that someone with better info could see such a move as a terrible mistake.)

<comment><USER6> AFAIK LINQ pretty much is a library since its just extension methods, in itself I don't there's any other specific language feature needed to support it, is there something else you had in mind?

I do agree though that LINQ seems to hint at and start evolving C# into a different semi-functional kind of language, and what we're stuck now with is a language with one foot in both worlds. Hopeful another language will come along one day and chisel out those ideas into a more pure form. (and I'm not meaning a pure functional language like for instance F#)

<comment><USER7> I mean that it is basically a DSL with special syntax, and that it would be nice to be able to write such things in libraries (without needing it to be part of the C# spec.)

There is obviously a relationship between code like

        .Select(blah).From(blah).Where(blah)

and

        SELECT blah FROM blah WHERE blah,

and I think it would be worthwhile to look into a language feature that allowed a reliable translation between these kinds of things. Maybe I want to write

        LET a = blah IN blah

from

        .Let(a, blah).In(blah)

or some such thing. It it just syntactical sugar? Is it a pattern that can be abstracted well?

<comment><USER6> Well, each linq "operator" is just an extension method to the ienumerable interface that are chained together. So nothing prevents you from doing your own operators.

Most of the features that came along around the time of LINQ (var variables, extension methods, anonymous classes, lambdas etc) was done specifically to support the LINQ kinda syntax but LINQ in itself is not so much part of the language as it is of the .net libraries.

Btw, I personally think the "dot notation" syntax is superior to the "query expression". It's easy to follow from start of the line to the end and you get great autocompletion along the way.

<comment><USER8> Generally agree, but it depends a lot on the query. I find that join syntax especially is more readable in the query style.

<comment><USER9> I liked chaining expressions for things that were done in memory and query style for deferred. My brain handled the code a bit better when things were written that way.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Null-conditional operators is going to be a real nice thing to have and somethings that's been requested for a long while. Saying that most of the other stuff seems to small nice to haves and cleanup.

I kinda wish they'd put more thought and energy into some tidy way of doing error checking, pre-conditions etc. locating and avoiding bugs is still one of the main concerns in any project and not enough are done to help with that. There are extensions but they are all a little clunky or require too much effort.

If they did that correctly I think it could be a game changer on par with Linq and rx

<comment><USER4> pre/post conditions can be handled via [https://github.com/ghuntley/conditions](https://github.com/ghuntley/conditions) or via code contracts. Conditions runs on all platforms (mono/windows/xamarin mobile) and does runtime inspection vs Code Contracts which unfortunately runs only on Windows but does have the added advantage of being able to specify behaviour on interfaces and validation being performed at compile time. There was a project w/GSOC back in 2010 that tried to bring Code Contracts across [http://monocodecontracts.blogspot.com.au/](http://monocodecontracts.blogspot.com.au/) which got merged w/ Mono 3.0 but the corresponding tooling in MonoDevelop is missing so it is useless. See [http://www.mono-project.com/docs/about- mono/compatibility/](http://www.mono-project.com/docs/about- mono/compatibility/) for more information and please bump this ticket [https://bugzilla.xamarin.com/show_bug.cgi?id=8400](https://bugzilla.xamarin.com/show_bug.cgi?id=8400) in support.

<comment><USER10> The problem with code contracts is that they aren't available across all versions of .NET, even on Windows.

You need at least the Premium edition for the required tools.

<comment><USER11> Code Contracts were just released under MIT license on GitHub which (I'd think) will probably positively affect their availability [https://github.com/CodeContractsDotNet/CodeContracts](https://github.com/CodeContractsDotNet/CodeContracts)

Update: On second thought, I think Code Contracts were already available on the free Visual Studio 2013 Community edition: [https://visualstudiogallery.msdn.microsoft.com/1ec7db13-3363...](https://visualstudiogallery.msdn.microsoft.com/1ec7db13-3363-46c9-851f-1ce455f66970)

<comment><USER12> The other problem w/ Code Contracts is inheritance. A call to base.DoStuff(arg); might fail, even though the child class handles it and doesn't need the contract to be satisfied by the parent.

<comment><USER10> That is not an issue.

Have you read the whole principles behind code contracts?

Derived classes must uphold the same contracts as the base classes, they are only allowed to strengthen them, not to drop conditions.

<comment><USER13> Is there a difference between design-by-contract and the condition modifications allowed by the Liskov substitution principle? They seem related but I'm not well-enough versed in the differences.

"...the subtype must meet a number of behavioral conditions. These are detailed in a terminology resembling that of design by contract methodology, leading to some restrictions on how contracts can interact with inheritance:

Preconditions cannot be strengthened in a subtype.

Postconditions cannot be weakened in a subtype.

Invariants of the supertype must be preserved in a subtype."

[http://en.wikipedia.org/wiki/Liskov_substitution_principle](http://en.wikipedia.org/wiki/Liskov_substitution_principle)

<comment><USER10> They are the same.

I was generalizing and though only about pre-conditions.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> In case you prefer video format, this is from a talk I did a while back: [https://www.youtube.com/watch?v=fNTf680fTHE](https://www.youtube.com/watch?v=fNTf680fTHE)

</comment><comment><USER15> I'm happy C# is adopting more from F#, but only half joking, where are all the comments complaining that new syntax and more operators make code harder to read? Every time there is an article about F#, half the comments are people saying how it has too many operators. Add a few more to C# and every comment is praise.

<comment><USER16> F# tries to make things too concise. I think it would be more approachable having curly brackets and maybe less inference (or bring great tooling and actual killer features). Love the immutability and non-null default!

Ideal language for me is somewhere between C# and F#. C# is moving there (but F# doesn't).

<comment><USER15> If you want "actual killer features", they'd by definition be unreadable, since you've never seen them before. I used to think F# was unreadable, then I realized it was those killer features that have no "curly equivalent" that was tripping me up. Once I learned them, it became easier to read.

Before I knew what lambdas were JS was hard to read too, and before I learned inheritance both Java and C# were confusing messes.

And what would F# need to move to? You can type out the types now, you can do all the OO of C#. The only thing I can think you mean is as add curly braces around functions and classes, which wouldn't make it objectively easier to read, just more familiar to some C# developers. Unless you mean add higher kinded types, but that would move it closer to Haskell.

</comment></comment></comment><comment><USER17> Check out live interactive examples of the new C# 6 features at [http://ahuwanya.net/blog/post/Exploring-C- Sharp-6](http://ahuwanya.net/blog/post/Exploring-C-Sharp-6)

</comment><comment><USER6> One thing about the null checking stuff that I started thinking about... wouldn't it be more cleaner and less error prone if accessing subproperties of null classes always returned null instead of an exception? ie:

var someVar = class1.class2.SomeProp;

would return null, even if class1 was null. I have a hard time coming up with cases where you actually would want to force an exception. I realize however they reason for the new operator since they might not want to change how existing code works...

<comment><USER18> I think this has to do with types. In what you propose the returned type for primitive types (int, ...) would always be `Nullable<T>` and you would have to cast them to get the type `T`.

In many cases you can guarantee that the sub-property is not null and you can safely access the value. I think the proposed operator `.?` is the perfect solution and gives you the flexibility to decide what you can guarantee and how you want to access the sub-property.

<comment><USER6> I don't think you should involve nullables ,the compiler would simply rewrite to check if link in the chain is null and then assign to null.

But value types are a good point, either it could then set it to default(T) or not set it at all, but it kinda has to be default(T) because null makes most sense for reference types. Might give some unexpected behavior if it variables are set to 0 because of a null reference

</comment></comment></comment><comment><USER19> Great features.

I'm most excited about being able to watch the result of lambda functions while debugging (not mentioned here), should make things much easier.

<comment><USER4> After async in a catch/finally this is the other thing I'm most excited about. Being able to watch/unwind the result of a lambda will make working w/UI's developed in a functional reactive programming manner w/RX so much easier.

</comment></comment><comment><USER20> I don't understand this:

> int? length = customers?.Length; // null if customers is null

Surely, a primitive int cannot be null (at least in Java).

<comment><USER21> The 'int? length' declares length as a nullable int.

[http://msdn.microsoft.com/en- us/library/1t3y8s4s.aspx](http://msdn.microsoft.com/en- us/library/1t3y8s4s.aspx)

<comment><USER20> > The 'int? length' declares length as a nullable int.

Thanks; this shows how rusty my C# skills have become.

<comment><USER16> Don't blame yourself, blame Java.

<comment><USER9> I haven't touched Java since school yet it feels like nothing major has changed in terms of writing code (outside of tools of course). I haven't coded in C# for 2 years and I feel like I need some time to catch up. Seeing the difference between the languages makes me feel like people who only do Java are going to be hopelessly left behind.

</comment></comment></comment></comment></comment><comment><USER22> Looks like the named string expressions e.g. \\{p.Age} were inspired by Swift's \\(p.Age)

<comment><USER16> I hate to break it to you, but there is literally nothing in this world inspired by Swift (yet). The language is simply too new and too derivative. Quite "innovative" for Apple dev world, though.

<comment><USER23> Rust recently added `if let` bindings, specifically inspired by Swift. But apart from that I agree.

</comment></comment></comment><comment><USER24> nameof(x) ... I like that. Any performance impacts? Sounds like some reflection would be required to do that behind the scenes ...

<comment><USER25> Actually I doubt that. Haven't read the specifics, but for me that sounds like a compile time feature.

C# already has a ton of those, the most prominent so far are extension methods.

Foo.Blergh()

can be implemented by a class that offers

static void Blergh(this Foo foo) {}

and the compiler will just replace the call above, looking like a specific thing Foo can do with

SupportingClass.Blergh(thatFooInstance)

I'd say the nameof() implementation is most likely similar and will just replace the name of the local symbol with the symbol itself, during the compilation.

<comment><USER26> > a compile time feature. C# already has a ton of those, the most prominent so > far are extension methods.

Yes, nameof is compile-time. Similarly, the ?. generates code (a "? :" or if statement) and so does the string interpolation (a call to string.Format).

I've even sketched an outline of a talk of the c# language features that are "just" sugar. e.g. walking through a statement like

      var evens = numbers.Where(x => x % 2 == 0);

and showing what it looks like without the compile-time sugar features like the lambda, extension method use of "Where", "var" inference, etc.

Of interest I suppose to just-beyond-beginner devs

<comment><USER25> Did you document that somewhere? I might be interested to share that internally. We're C# shop, but quite a number of my coworkers aren't exactly up to speed and a "Let's talk about 3.5 and upwards" session is planned in a couple of weeks..

<comment><USER26> That talk is not very mature yet ;) If I ever give it then there will be be slides.

</comment></comment></comment></comment></comment><comment><USER27> using static

That will clean up quite a bit of my code.

<comment><USER28> Am I mistaken or did they actually forget to use the "using static" statement in the example? That way it gets really clean and confusing.

I'm missing a line that says

        using static Math.Sqrt;

<comment><USER29> You're mistaken, kinda. The syntax wasn't originally "using static", it's just "using" but with a qualified class name instead of a namespace name. The example includes:

      using System.Math;

System.Math is a static class, not a namespace. It doesn't import a single static method, it imports the entire class.

However, in the italicized note, you can see they changed their minds after releasing the preview. It's going to be "using static", but they didn't update the example. It will still operate on the entire class and not an individual method though.

<comment><USER28> Ah my bad I was looking for an explicit "using static" & forgot math is a static class and not a ns.

</comment></comment></comment></comment><comment><USER30> Eh, a lot of this looks cool, but doesn't solve any really hard problems.

It's easy to mess up a null check, but it's equally easy to find the bug and fix it.

It's easy to mess up a string format, but it's equally easy to find the bug and fix it.

It's easy to mess up a chain of Rx event streams and when you do--you're out of luck buddy. Have fun debugging that.

Async rewriting for error handling does solve a really difficult problem, but there are much deeper problems with using C# for the kind of imperative threading code where that problem comes up. I wouldn't write that in C#, that's certain.

<comment><USER16> Nested null-checks are a lot of code without the existential operator: if(){if(){if()}}} vs .?.?.?

<comment><USER30> Like I said, doesn't solve any hard problems. If having to type an extra few if-statements is the hardest programming problem you have to solve all day, you have a damn easy job.

Don't get me wrong: I like that syntax change--I'm all for shorter, cleaner code. But I've moved on from C# because it was ineffective for solving hard problems like multithreading, scaling, networking, crypto. Eliminating a few if statements doesn't fix that.</comment></comment></comment>


Observium: An auto-discovering network monitoring platform - <AUTHOR> http://www.observium.org/

<comment><USER2> Another system focused on the wrong thing in monitoring: on alerts and charts. Those are merely methods of consuming data, not the only ones and not even the most important ones a decent monitoring system should do.

Sending e-mail or displaying a set of charts or a status table is simple. Allowing to collect, collate and aggregate the data (metrics and events) in arbitrary way, also as an afterthought, is what monitoring system should do. With virtually everything on the market, when a need for any processing not anticipated by monitoring system author arises, one needs to write much stuff outside said system.

We need less systems resembling invoicing systems and more systems resembling general purpose databases.

This is why monitoring _still_ sucks.

<comment><USER3> It's not clear to me what you're looking for. Most monitoring systems log to a general purpose database, so can't you query against that database when you want to analyze your data?

I admit I do very little systems/network administration work, so maybe there's something I'm missing.

<comment><USER2> Those monitoring systems use some backends, sure. RRD/Whisper, SQL databases, some even use NoSQLs. But all those are abstractions on inappropriate level with regard to monitoring. You can't do stream processing on those. You can't do processing in real time. The only viable operation is to query historic data; even then, it's hardly doable.

Also, you say I can query against such database. But does the monitoring system allow me to query that database? I have no documentation for it. Most of the time I can't easily fill events generated out of that back to the database. And at last, current so-called "state of the art" monitoring systems don't facilitate running custom queries, so I would need to write something totally external just to run the query.

Graylog2 and Riemann go a little in this way, but they stopped way, way too soon to be an answer to current state of monitoring systems.

</comment></comment></comment><comment><USER4> This is a great free tool, just don't ask for something the developer doesn't agree with. He and the IRC community supporting it will tear you to shreds.

<comment><USER5> I agree with this, the developer on this is no doubt good at what he does, but him and the community that supports him is very poisonous. Does not take criticism well, and is generally hateful to people who say something he doesn't agree with.

<comment><USER6> Do you have any examples? I am not teasing here with you. Seriously I'd like to know what they do since I'm still looking for monitoring solution (currently testing munin).

</comment></comment></comment><comment><USER7> Also check ntop out -- it has similar traffic reports, but no such fancy multibox support last time I looked.

That's more a job for SNMP clients anyway. Actually, just look at Nagios/Icinga :) It's a very mature and well-rooted infrastructure monitoring solution.</comment>


Plead HN: Build a functional apartment finding website. - <AUTHOR>

Make me a website that does the following and I promise you unbound riches:<p>- To select an area: Allow me to draw a region on a map.  No dropdown of giant arbitrary areas.  No checkboxes of giant arbitrary areas.  No keyword search to determine area.  Just let me draw a region.  Even a rectangle will do.<p>- To select a price: Allow me to enter a price range easily.  Not a dropdown with $500 price chunks.  Not textboxes where I need to type in numbers.  Just give me a slider with $100 increments.<p>- To view the results:  Show me the results.  Optionally, let me sort and filter.  Bonus points for showing number of results that have each characteristic (eg: doorman (5), outdoor space (15), etc).  Do not make me provide an email address to see results.<p>- Show me, within a block, where the listing is.  I am planning on living there.<p>- To trust you: Not 100% uppercase. Not as if every listing is the best listing on the planet.  No exclamation points, asterisks, triangles, trapezoids, or polygons of any sort.<p>- The big one: Have up to date listings.  I don't know how you will do this, but if you do it, you'll be rich.<p>Hipmunk for apartments.  Somebody get on this.  PLEASE. <comment><USER2> UI is the easy part. The listings that are accurate, honest and up to date are hard. Do you want to become a real estate company as well, hire your own agents, pick up the phones, take customers for the visits and so on? Or you need to provide a service that these companies (and some landlords, perhaps) want to use, in the right way.

Why would they give you out the exact address? A competing real estate company (not one, three, more) would immediately contact the landlord and offer him a better deal. Why would you list the price correctly, if you can hide some additional fees in the comment, stay 'technically' correct and look more attractive in the search?

I work on a service like this, we are quite rich (well, as a company, I'm just an employee), but we really can't do what you want. I'd like to, I don't like to use the service much, it's not bad itself, but it doesn't help you from dealing with the real estate agents and if I say that they are all liars and frauds, I'm not exaggerating at all.

(But we're in eastern Europe, things are perhaps different in America.)

<comment><USER3> What you describe sounds like an industry based on a pre-internet business model, waiting to be disrupted.

</comment></comment><comment><USER4> Here are some sites that have some similarity to what you described:

<http://www.padmapper.com/>

<http://www.walkscore.com/apartments/>

<http://hotpads.com/>

<comment><USER5> How is Padmapper able to list Craigslist properties without getting banned?

</comment></comment><comment><USER6> Sorry, I just don't see this as a big need. I mean looking for an apartment at the going rate is inconvenient, but I just don't see why the startup ecosystem should support yet another variant on this.

Here's my algorithm for looking for an apartment.

1) If I want to rent in a major, professionally managed building, just take one weekend and drive around the area I would like to live in. Honestly, it's old fashioned, but you're going to need to do this at some point.

2) If I am interested in renting from a small scale landlord or just renting a room then I use CL (and so apparently do all the startups in this space).

The apartment market is pretty darned efficient. If you think you've got a bargain, just wait. Maybe it will be mold, or noisy plumbing or bad neighbors, but whatever it is a problem will arise that will teach you just how efficient markets can be.

I just don't see the need for yet another apartment search site. Would it be nice? Sure. But would it solve a major pressing pain point? At least not for me and probably not for enough people that the business can get paid by users or advertisers and create a sustainable business model.

Now I do think the way we rent is fundamentally broken, but that's a business model problem that needs to address a broad set of pain points of renters and landlords.

For example, I think there are a lot of people in this economy who should be renting rooms out, but aren't (e.g. if you're unemployed and relying on my tax dollars to fund you AND you have a 4 bedroom house in a large MSA - maybe look into getting rid of some of your junk and monetizing your square footage).

Now if you're still reading this, you're probably coming up with a lot of reasons why someone just can't rent some of the excess square footage in their house. Now come up with a business model that honestly addresses all those reasons _, then execute that model. Then get rich. Thanks.

_ some potential solutions: better screening of applicants, semi-co-housing like solutions, helping homeowners move out of unnecessarily large homes and downsizing to smaller residences while renting out their former residences (could be useful for retirees who aren't willing to sell in this market, but want to downsize), help families set up au pair arrangements where part of the rent is paid for in services (this could alleviate the concerns of families with children who want to rent out a room, but are worried because they have kids). Bottom line - Americans have WAY too much square footage plus there's an emerging trend toward more minimalistic downsized lifestyles both for economic and cultural reasons. I don't know of any business that is helping people monetize their square footage.

If you've got any ideas+skills contact me and maybe I can help you raise some money.

</comment><comment><USER7> <http://padmapper.com>

<comment><USER8> awesome site

</comment></comment><comment><USER9> <http://www.apartmentlist.com> has most of those features. Plus it adds a recommender to help you sort through your search. It doesn't scrape Craigslist so the quality of the apartments is really high, and it still has 1.9 million of them.

It just launched in September, so expect to see more of those features you are looking for to go live soon.

<comment><USER10> Was just checking out apartmentlist.com for the first time:

"We need you to connect with Facebook so we can work our magic."

Why in the world...?

</comment></comment><comment><USER11> There is nothing that can force landlords who are too technophobic or just too lazy to post relevant photos, an exact address, and complete information to change their ways. Ver 2.0 of the apartment hunt may be coming, but not until Gen 2.0 are managing buildings.

</comment><comment><USER12> RentHop (YC S09) has most of these features, especially the one allowing you to draw the region on a map. The caveat is that they only serve the New York City market. <http://www.renthop.com/>

<comment><USER13> So does HotPads: the lasso below the zoom widget. <http://hotpads.com/>

</comment></comment><comment><USER13> > Just let me draw a region.

> Not textboxes where I need to type in numbers. Just give me a slider with > $100 increments.

You insist on specificity in one place, and you reject it in another place.

Your requirements aren't consistent.

Hotpads is pretty great. It has a lasso tool, and a more powerful price selection tool (the text fields). I suggest giving it another look. If it isn't quite up to par, Hotpads would be quicker in delivering what you want than a newcomer. I don't buy that Hotpads _just doesn't get it_.

<comment><AUTHOR> I cannot be consistent with apples to oranges. If I required a specificity of 10 feet in my region selection, what then would be the "consistent" specificity of the rent slider? $1, $10, $100?

Also, inconsistent requirements != inconsistent UI.

<comment><USER14> Yeah, I think your specs are pretty good, and there's no universal level of specificity, just what makes sense where. I wrote PadMapper - is there anything you'd like to see improved? Noted on the polygons.

</comment></comment></comment><comment><USER15> There's a site like that for Japan, unfortunately only in Japanese though:

<http://www.datadata.jp/chintai/>

You select a price range & other conditions, and a spot on the map with a radius, and it shows you all places that fit those requirements in that area. Very simple, very useful.

</comment><comment><USER16> Sounds exactly like Globrix: <http://www.globrix.com/>

</comment><comment><USER17> I'd also checkout <http://www.rentenna.com/>

</comment><comment><USER18> Also this: <http://livelovely.com/>

</comment><comment><USER19> My company has been working on this since June. Email me.

email@example.com

</comment><comment><USER20> try newpad.ca (in Canada)</comment>


South Korean government to shut off computers to stop its employees working late - <AUTHOR> http://www.bbc.com/news/world-asia-43497017 <comment><USER3> >However, not every government worker seems to be on-board - according to the SMG, 67.1% of government workers have asked to be exempt from the forced lights-out.

They asked to be exempt entirely on their own volition, or their managers "politely" asked them to consider sending in an exemption request? And this isn't a question in earnest because I already know the answer.

<comment><USER4> I'm someone who works a lot of overtime, and yet no manager has _ever_ asked me to work overtime. The reason for putting these rules in place is because for some people (myself included) working overtime is something that they do habitually -- even when they shouldn't.

Now that's not to say that my managers are not complicit in that. Working as a programmer, I find there is not much time pressure during the day (unless you break your server), but you have this long term stress where you are thinking, "I need to get X,Y, and Z done by <some date>". Often those deadlines are even self imposed. In fact, it is a normal underhanded trick to get programmers to estimate and commit to dates knowing that they are overwhelmingly optimistic. But the fact remains that in general we walk willingly into those long hours.

I've also worked at a high school in Japan and while the stress is different, the results are the same. I used to _hate_ national holidays because I knew that my workload wouldn't change. It just meant that I had one day less to get my work done, which is basically a whole lot more stress during the week in exchange for some random, government imposed "day off". I take my "day off" and my students get a crap class later that week (or if I'm really organised, two weeks later). I feel bad because I want every single one of my classes to rock.

But to get to the point, if someone said that I had to turn off my computer at some government imposed time of the day, you're damn right I'd want an exception -- because otherwise there will be weeks where I won't get my work done. I will feel bad because I want to get my work done and I _hate_ the idea of screwing over the customer because, "Well, not my fault! I have to go home".

Of course, you are perfectly correct to say that there is something very broken in that equation. You are wrong to assume that it's the evil manager to is squashing everybody under their thumb. I've had some right asses as managers before, but the vast majority have been wonderful, caring, people who have exactly the same illness I do.

That's why you mandate going home time, despite how much someone complains.

<comment><USER3> The problem here in Asia is every manager loves working day and night, destroying their family life (or preventing themselves from even having one) and developing zero interests outside of work until they're of retirement age.

The problem is that the people under the manager aren't all like this. Especially not 67.1% of them.

The problem is that the vast majority of managers will ask you why you're in such a hurry to leave. It's _only_ 8 o'clock and I'm still here. Are you implying that your business is more important than mine? Everyone else is staying here, so why are you leaving so soon? You know, if you keep leaving early, our division might not do well enough and we can't pay bonuses (which are really a full month's income that we deduct from your normal pay hold over your head for times like this). Is your wife asking you to come home early? I don't think a woman like that is good for you.

I'll be frank, you're an exception. Most people here don't want to work overtime. The problem is they know that they _need_ to, and they need to pretend to want to, or they'll be dealing with stuff like this every single day. Programmers are odd folks and we tend to like solving problems on our own, and money only makes it better. The average office worker in Japan making Excel spreadsheets at a rate of 2 boxes an hour isn't eager to be sitting there any longer. They're just know kacho will be on them and making them feel worthless because they're young and don't know the value of sacrificing their valuable life for the monetary gain of the CEO who inherited the company from his dad and never worked a day in his life.

People who sleep more and do less overtime are more productive than those doing needless overtime. And when it comes to Asia, virtually all overtime is needless overtime. If work piles up from basic holidays or not putting in excess time, there are one of two problems: people aren't using their time properly, or more likely, companies should be hiring more people.

<comment><USER4> I suppose we've had different experiences. I think virtually everyone would like to leave earlier, but the point is that they _also_ don't want to disappoint. In my experience, it's not about kacho watching over them -- they'd still be there if kacho went home (and I've personally seen that the few times kacho went home early). The kacho is only there to be loyal to the workers -- he wants to leave too. Or at the very least he wants to go out for a drink.

There definitely _are_ people watching the clock and desperately trying to look busy while doing nothing, but again my experienced is that those people are pretty much despised by everybody else on the floor. There is a ton of work to be done.

I only ever worked at the one school, but I have a really hard time believing that my school had exceptional workers. In fact, it was ranked near the bottom and was the place that problem teacher were sent in order to improve.

We could argue about this forever I suppose. I don't disagree that the work methodology is needlessly inefficient, but I strongly disagree that your first sentence is true. The work culture here is different and _everybody_ participates in it. There are parts of the work culture here I miss now that I'm working remotely for a UK company -- especially the dedication to working as a team.

<comment><USER5> I was born and raised in South Korea, and I have multiple years' worth of work experience in my home country. While I do agree that this argument could most definitely go both ways, I do think that 67% of workers opting to stay longer goes on to show just how prevalent the concept of "face-timing" at work really is in my country, regardless of which profession you work in. I can personally attest to many nights - more than majority of my work days, in fact - <USER2> I've found myself and my teammates working (or pretending to, at least) late into the night, just because my manager gave no signs of leaving anytime soon.

Unlike here in the States, individualism is not a value that society values; rather, it's essentially frowned upon. Confucianism manifests itself in modern society by being extended into the workplace; the idea of "we're all in this together" is almost forced upon workers, even in situations where it's clearly more of an individual thing. When your manager is working up until 10PM, I don't think a lot of Koreans would find it easy to leave work at 7PM, even when the work that's been allocated to her/him has been done.

</comment></comment></comment></comment></comment><comment><USER6> This is Bizarro world for me. Until I read this article I couldn't conceive that government workers working too hard would be an issue. Not that we don't have government workers who have to work really hard in the USA. But that seems to be the exception and not the rule. I am more used to watching the reflection of a game of Solitaire off of workers glasses while dozens of people wait in line.

I get that it's apparently a problem there, but what are they doing right where more than half the government workforce are asking to be allowed to work late? Or are they just milking overtime pay? The latter would definitely fit much more comfortably into my experience.

Edit: "My experience" being running a small business for 7 years that required interacting with various local government employees from many different municipalities. The vast majority were very nice people, but my company (and my competitors) were run way more efficiently, and always using the latest technologies. I think it comes down to motivation and human nature. Sometimes they would casually do things that completely screwed over everyone that relied on them, in the worst places such things would be done on purpose for political reasons. The office just got asked to reduce expenses by 5%? Cut the hours for customer facing tasks by 50% so the public feels the pain and complains to the mayor.

<comment><USER7> I've increasingly found the characterization that most government employees are lazy or inefficient to be remarkably untrue.

<comment><USER8> Yeah, I've never understood that characterization. The government as a system is inefficient, precisely because it doesn't operate on a profit motive.

But that's a systemic problem, not an individual one. Most of the people I know who work in government do so at a substantial pay cut compared to private sector work, and precisely because they're engaged and driven.

<comment><USER9> Why do people still believe that profit motive = efficient? My employer is plenty profit-driven, but a coworker just spent five days dicking around doing nothing because his computer broke and we're too incompetent to provide adequate spare resources. Don't tell me the profit motive makes organizations efficient.

<comment><USER10> It's a misleading simplification. Profit motive (or "private sector") is not equal to efficiency. But it's a _strong motivator for it_. Not perfect though, and the further you are from getting outcompeted and dying, the more space you have for inefficiencies to creep in.

One of the big sources of inefficiency affects governments and companies the same - the difficulty of keeping an organization functioning grows superlinearly with the number of people in it. That's why in a small company, if your computer breaks, you can just borrow the company card and go to the nearest store to buy a new one, while in a large company, you'd be dealing with procurement and five layers of management approvals. A large company looks not quite unlike a government organization.

(Also worth mentioning that absolute efficiency is not a good thing either, when it comes to dealing with people.)

<comment><USER11> I agree.

But a government has (self-imposed) financial constraints as well.

Besides, if you decide mostly or only based on financial constraints and not based on reason and good ideas then you should not be in the position to decide what to do.

Resources might be wasted on purpose to avoid tighter financial constraints in the next year that takes into account the spending of the current year.

</comment></comment></comment></comment></comment></comment><comment><USER12> This sounds like a good start but it should really be implemented at the human level by having managers convince their people to go home (with their work in whatever state it is in). Without the blessing of your superiors this situation could backfire and managers might apply more pressure to finish before the Friday shutdown.

<comment><USER13> What will happen is people will be sitting at their desks playing on their phones or sleeping. Until the governments of Japan and ROK decide to enforce their existing labor laws none of these "clever" solutions (like "premium Friday" in Japan) will change much.

</comment></comment><comment><USER14> There are various reasons that people may ask to be exempt. Two that most comes to mind are:

1\. Explicit or roundabout pressure from the managers

2\. Being expected to produce the same outcome despite reduced work time

Both of which seems like a inertia issue with the culture not following the change. That would probably stabilize over time if a actual rule sets in place.

</comment><comment><USER15> A crucial aspect of this story is that government employees are a coveted job in Korea, with a good benefits and salary and a healthy pension.

There are separate tests that people have to take in order to apply for gov jobs, and the competition rate is usually very high for all of them, clerical, skill-based, or not - from 40:1 to more often 200:1 of an apply/acceptance ratio.

This generally means that the level of skill and aptitude you encounter is very high; the amount of social morale is high also, since a government job is a respected, very healthy middle-class job.

</comment><comment><USER16> Having just shutdown my laptop at 9:30 PM MST (on my chromebook now) I just realized I work like a South Korean. No one asked me to work like this today. I was literally thinking how I am creating my own work prison and then I saw this article. At least I'm not alone? Ugh.

<comment><USER17> Please consider working only your alloted hours, as per your contract. It's very unheathly to work beyond 8 hours per day, maybe even 5-6 hours -- consider your health.

<comment><USER16> Agreed, some days I only do 4-6 so when I do days like this I feel like it balances out. Maybe I should start doing my own time sheets though. Working from home its really hard to tell. As for contract I am salary like most engineers.

<comment><USER18> Check out RescueTime

<comment><USER19> I assume you're familiar with that product?

Am I reading this correctly: You're running an agent on your various devices that sends data to their cloud? Application names at minimum, I assume. Website addresses as far as I can tell. If they harvest window titles: Probably file names you open.

Are you comfortable with that?

<comment><USER18> I don't use it, but it doesn't seem significantly riskier than using cloud- based email or any other proprietary desktop software.

</comment></comment></comment></comment></comment></comment><comment><USER20> Are these people working overtime all working or putting in face time?

<comment><USER21> From my experience living in Korea and the fact that Korea has one of the lowest productivity of all oecd countries, it is half-half.

A lot of the time is actually not "hard-working" but rather drizzling some work.

This is partly because you know it is expected that you stay long hours (and so you stay long hours without being explicitly asked) so you might as well just do your work slowly.

Also it is partly that nobody can work concentrated for such long hours. And a lot of time is wasted by people not asking when they are stuck with any kind of problem / task (losing ones face / looking incompetent problem).

</comment></comment><comment><USER22> More precisely, this appears to be for governmental employees only.

</comment><comment><USER23> What about those who work late away from computers?

<comment><USER24> Can't solve the entire workaholic problem at once, baby steps. Next steps would be to nuke service access after business hours (email, remote desktop, etc).

Both Germany [1] and France [2] passed laws restricting the use of business email after work hours to ensure proper work/life balance.

[1] [https://www.npr.org/sections/parallels/2014/12/01/366806938/...](https://www.npr.org/sections/parallels/2014/12/01/366806938/german- government-may-say-nein-to-work-emails-after-six)

[2] [https://www.nytimes.com/2017/01/02/world/europe/france- work-...](https://www.nytimes.com/2017/01/02/world/europe/france-work- email.html)

<comment><USER25> I really like flexibility. To me that's the balance. If they set your work hours how do you have balance? For example, dr appointment or meeting kids teacher in the middle of business day. The balance is being able to jump online that evening when you get home, IMO. So I'm always curious about how these mandated work hour things are implemented and enforced. Because if they just shut off the systems at 5pm, then you're just missing work. That's not balance.

<comment><USER24> Or just start fresh in the morning.

There are reasons these regulations are being enacted. Reducing abusive workplace environments takes priority over flexibility and convenience.

</comment></comment></comment></comment><comment><USER26> Government workers working hard?! Must be a nice problem to have.</comment>