Monday, 30 January 2017

Introduction · A Guide to Porting C and C++ code to Rust

Introduction · A Guide to Porting C and C++ code to Rust: "This book is for people familiar with C or C++ who are thinking of using Rust.
"

Normally such software would be written in C or C++, but consider these every day programming issues that afflict these languages:
  • Dangling pointers. A program calls an invalid pointer causing a crash.
  • Buffer overruns / underruns. Code writes beyond an allocated buffer causing memory corruption or a page exception.
  • Memory leaks. Code that allocates memory without calling the corresponding free action.
  • Data races. Multiple threads write to data at the same time causing corruption or other destabilizing behavior.
Rust stops these bad things happening by design. And it does so without impacting on runtime performance because all of these things are checked at compile time...
'via Blog this'

How to free disk space on Linux systems - TechRepublic

How to free disk space on Linux systems - TechRepublic: "The Linux operating system is well known for its powerful command line functionality. As a system administrator, I operate a few hundred Linux servers and most of them don't even utilize a graphical user interface such as KDE or Gnome. Maintenance of our servers requires extensive knowledge of various helpful (yet complex) commands to keep them healthy.

Disk space is frequently a headache with systems that store and write a lot of data (some useful, and some not). While QDirStat, GdMap, xdiskusage and Gnome's Disk Usage Analyzer are all useful examples of graphic-based utilities to measure disk space usage, I have a toolkit of my own commands which I use from the command line and it's safe to say they're indispensible to me. Here are a few of my favorite examples."



'via Blog this'

Saturday, 28 January 2017

4 essential skills software architects need to have but often don’t - O'Reilly Media

4 essential skills software architects need to have but often don’t - O'Reilly Media: "Microservices. Continuous delivery. Reactive systems. Cloud native architecture. Many software architects (or even aspiring ones) have at least a passing familiarity with the latest trends and developments shaping their industry. There are plenty of resources available for learning these topics, everything from books and online videos to conference presentations; the ability to go from novice to expert in these areas is right at their fingertips. However, as today’s trends quickly bleed into tomorrow’s standards for development, it’s paramount that software architects become change agents within their organizations by putting into practice the “unspoken” side of their skill set: communication and people skills"



'via Blog this'

RipVanWinkle.js — Returning to JavaScript After 5 Years

RipVanWinkle.js — Returning to JavaScript After 5 Years: "I got JavaScript fatigue before it was fashionable, way back in 2011. I basically ignored the entire ecosystem — including Node — in the interim, while happily programming away in Python 3 and its excellent stats libraries.
This past year, a number of great summaries of the JavaScript ecosystem were published, including the quite critical How it feels to learn JavaScript in 2016. In reading these articles, I realized that everything I knew about JavaScript and its platform was just completely out-of-date. ES2015? Arrow functions? Transpilers? Babel? React?
It was like people were talking in a foreign language — and they were, for the JavaScript I had grown up with was dead, and had been replaced with something far better (although still with quirks)."



'via Blog this'

SKIDL | PYTHON → CIRCUITS

SKIDL | SKIDL: "Never use a lousy schematic editor again! SKiDL is a simple module that lets you describe electronic circuits using Python. The resulting Python program outputs a netlist that a PCB layout tool uses to create a finished circuit board."



'via Blog this'

technologyreview: Programming Languages: Toolkits for the Mind

Toolkits for the Mind: "When the Japanese computer scientist Yukihiro Matsumoto decided to create Ruby, a programming language that has helped build Twitter, Hulu, and much of the modern Web, he was chasing an idea from a 1966 science fiction novel called Babel-17 by Samuel R. Delany. At the book’s heart is an invented language of the same name that upgrades the minds of all those who speak it. “Babel-17 is such an exact analytical language, it almost assures you technical mastery of any situation you look at,” the protagonist says at one point.



With Ruby, Matsumoto wanted the same thing: to reprogram and improve the way programmers think.

It sounds grandiose, but Matsumoto’s isn’t a fringe view. Software developers as a species tend to be convinced that programming languages have a grip on the mind strong enough to change the way you approach problems—even to change which problems you think to solve. It’s how they size up companies, products, their peers: “What language do you use?”



 That can help outsiders understand the software companies that have become so powerful and valuable, and the products and services that infuse our lives. A decision that seems like the most inside kind of inside baseball—whether someone builds a new thing using, say, Ruby or PHP or C—can suddenly affect us all. If you want to know why Facebook looks and works the way it does and what kinds of things it can do for and to us next, you need to know something about PHP, the programming language Mark Zuckerberg built it with."



'via Blog this'

Why I Switch From [Language_1] to [Language_2]

Why I Switch From [Language_1] to [Language_2]: "I am a big fan of [Language_1] and one of its early adopters, having been disappointed with the utter failures of [Language_0]. I have been an avid contributor to many open source projects such as [Obscure_Project_1], [Obscure_Project_2], and [Obscure_Project_3]. However, after using [Language_1] for over 5 years, I have been dealing with [Minor_Technical_Flaws]. At first, I ignored and even tolerated these flaws, but I was forced to confront reality. I could not live with these flaws, and since [Language_1] is a mature language, it will be difficult, if not impossible, to actually fix [Minor_Technical_Flaws]."



'via Blog this'

“My Code is Self-Documenting” — Eric Holscher - Surfing in Kansas

“My Code is Self-Documenting” — Eric Holscher - Surfing in Kansas: "Self-documenting code is one of the biggest documentation myths in the software industry. This view generally conflates documentation with code comments. I’d like to make two arguments in this post:

Code comments have value
Documentation has more value than just explaining how software works"



'via Blog this'

Thursday, 26 January 2017

Original Rust introductory slidedeck



http://venge.net/graydon/talks/intro-talk-2.pdf



'via Blog this'

Google Infrastructure Security Design Overview  |  Google Infrastructure Security Design Overview  |  Google Cloud Platform

Google Infrastructure Security Design Overview  |  Google Infrastructure Security Design Overview  |  Google Cloud Platform: "  Google has a global scale technical infrastructure designed to provide security through the entire information processing lifecycle at Google. This infrastructure provides secure deployment of services, secure storage of data with end user privacy safeguards, secure communications between services, secure and private communication with customers over the internet, and safe operation by administrators.
Google uses this infrastructure to build its internet services, including both consumer services such as Search, Gmail, and Photos, and enterprise services such as G Suite and Google Cloud Platform.



The security of the infrastructure is designed in progressive layers starting from the physical security of data centers, continuing on to the security of the hardware and software that underlie the infrastructure, and finally, the technical constraints and processes in place to support operational security.
Google invests heavily in securing its infrastructure with many hundreds of engineers dedicated to security and privacy distributed across all of Google, including many who are recognized industry authorities.
Introduction

This document gives an overview of how security is designed into Google’s technical infrastructure. This global scale infrastructure is designed to provide security through the entire information processing lifecycle at Google.


'via Blog this'

xkcd: Functional Programming

xkcd: Sad: "



'via Blog this'

Wednesday, 25 January 2017

Making the move from Scala to Go, and why we're not going back | Movio Movio Blog

Making the move from Scala to Go, and why we're not going back | Movio Movio Blog: "Here’s the story of why we chose to migrate from Scala to Go, and gradually rewrote part of our Scala codebase to Go. As a whole, Movio hosts a much broader and diverse set of opinions, so the “we” in this post accounts for Movio Cinema’s Red Squad only. Scala remains the primary language for some Squads at Movio."



'via Blog this'

Monday, 23 January 2017

Short intro to C++ for Rust developers: Ownership and Borrowing

Short intro to C++ for Rust developers: Ownership and Borrowing: "ince I got C++ job after learning Rust, I thought it would be interesting to write a summary how one would adapt to C++ with some prior Rust experience.

I would assume the reader already knows C++ syntax and features, and would be interested in how one would fit concepts to C++ from Rust world.

In this post, however, I could not fit everything I wanted to write, so I will focus on Ownership, Borrowing and Lifetimes."



'via Blog this'

Wednesday, 18 January 2017

Dismissing Python Garbage Collection at Instagram

Dismissing Python Garbage Collection at Instagram: "By dismissing the Python garbage collection (GC) mechanism, which reclaims memory by collecting and freeing unused data, Instagram can run 10% more efficiently. Yes, you heard it right! By disabling GC, we can reduce the memory footprint and improve the CPU LLC cache hit ratio. If you’re interested in knowing why, buckle up!"



'via Blog this'

Monday, 16 January 2017

Scaling Python is on its way | Julien Danjou

Scaling Python is on its way | Julien Danjou: "I started to dig into a lot of different fields around Python. Topics you don't often look at when writing a simple and straight-forward application. It turns out that writing scalable applications in Python is not impossible, nor that difficult. There are a few hiccups to avoid, and various tools that can help, but it really is possible – without switching to another whole language, framework, or exotic tool set.

Working on those projects seemed to me like a good opportunity to share with the rest of the world what I learned. Therefore, I decided to share my most recent knowledge addition around distributed and scalable Python application in a new book, entitled The Hacker's Guide to Scaling Python (or Scaling Python, in short). The book should be released in a few months – fingers crossed."



'via Blog this'

WestMonroe: A Beginner’s Guide to Leaf-Spine Networking Topology

A Beginner’s Guide to Leaf-Spine Network Topology: "There is a new trend for network topology design standards — creating a fast, predictable, scalable, and efficient communication architecture in a data center environment. This article provides an introduction to Leaf-Spine network topology."



'via Blog this'

Sunday, 15 January 2017

Learning systems programming with Rust - Julia Evans

Learning systems programming with Rust - Julia Evans: "I did the closing keynote at the first RustConf yesterday, on Rust and systems programming and accessibility and learning about concurrency and why I write about programming and a bunch of other things.

I was really delighted to be invited because I’m a huge fan of the Rust community. They’re working incredibly hard to make a language that is extremely powerful, but also easy to use, and there was a huge focus on usability and good error messages. The talks were really ambitious, friendly, and inclusive. Their challenge is “Fast, safe, productive – pick three” :).

Here’s a video & transcript of that talk (where when I say “transcript” I mean “more less what I said, kinda”)."



'via Blog this'

Thursday, 5 January 2017

Google Open Source Blog: Grumpy: Go running Python!

Google Open Source Blog: Grumpy: Go running Python!: "Grumpy is an experimental Python runtime for Go. It translates Python code into Go programs, and those transpiled programs run seamlessly within the Go runtime. We needed to support a large existing Python codebase, so it was important to have a high degree of compatibility with CPython (quirks and all). The goal is for Grumpy to be a drop-in replacement runtime for any pure-Python project.
Two design choices we made had big consequences. First, we decided to forgo support for C extension modules. This means that Grumpy cannot leverage the wealth of existing Python C extensions but it gave us a lot of flexibility to design an API and object representation that scales for parallel workloads. In particular, Grumpy has no global interpreter lock, and it leverages Go’s garbage collection for object lifetime management instead of counting references. We think Grumpy has the potential to scale more gracefully than CPython for many real world workloads"

'via Blog this'

Wednesday, 4 January 2017

Porting Python 2 Code to Python 3 — Python 3.6.0 documentation

Porting Python 2 Code to Python 3 — Python 3.6.0 documentation: "A key point about supporting Python 2 & 3 simultaneously is that you can start today! Even if your dependencies are not supporting Python 3 yet that does not mean you can’t modernize your code now to support Python 3. Most changes required to support Python 3 lead to cleaner code using newer practices even in Python 2 code.

Another key point is that modernizing your Python 2 code to also support Python 3 is largely automated for you. While you might have to make some API decisions thanks to Python 3 clarifying text data versus binary data, the lower-level work is now mostly done for you and thus can at least benefit from the automated changes immediately.

Keep those key points in mind while you read on about the details of porting your code to support Python 2 & 3 simultaneously."

'via Blog this'

Getting Past C : Rust / Go

Getting Past C: "Now for the exciting questions: which language, and when?

We don’t have answers to those yet, but the field is narrowing and the time we might attempt a translation is getting closer - in the most optimistic case it could be as little as 6 to 9 months out. The catalyzing event is not just the emergence of two plausible candidate languages but the fact that both seem now to have reached a self-sustaining community size, so we can be reasonably confident they won’t croak and leave us stranded.

No prize for guessing that our two plausible candidates are Go and Rust.

There’s lots of web evangelism around both languages, so I’m not going to attempt a detailed comparison here. I’m just going to hit a few high points about how their traits intersect with NTPsec’s particular needs.

Probably the first question that will occur to a lot of you is: "Huh? Wouldn’t the stop-the-world pauses from garbage collection rule out Go? And the answer is…​they might, but (a) the actual time-critical sections in NTP are small and wrapped tightly around the clock-manipulation calls, and (b) Go’s runtime allows you to lock out GC during critical sections.

In any case, the Go developers have a pretty convincing story about holding stop-the-world pauses down to the small-number-of-milliseconds range. We’ll have to measure, but that just might be tolerable even without the GC lockout.

Still, the absence of GC overhead is a point in Rust’s favor. So is Corrode, the automatic C-to-Rust translator. The Go developers wrote a translator to move their Go compiler from C to Go, but it has no documentation and "Here Be Dragons!" warnings in the README.

Russ Cox’s talk on the C-to-Go translator claims it handles a large subset of C that notably does not include…​unions and certain kinds of goto. These are restrictions we can deal with. It may be usable. And if it’s not, maybe I can up-gun it until it is - language parsing and translation is a kind of problem I’m pretty good at and enjoy working.

In the end it might come down to which language I feel more comfortable in. (It’s good to be king the principal coder at times like this.) And I don’t know which that’ll be yet."

'via Blog this'

Sunday, 1 January 2017

The memory models that underlie programming languages

The memory models that underlie programming languages: "There are about six major conceptualizations of memory, which I’m calling “memory models”², that dominate today’s programming. Three of them derive from the three most historically important programming languages of the 1950s — COBOL, LISP, and FORTRAN — and the other three derive from the three historically important data storage systems: magnetic tape, Unix-style hierarchical filesystems, and relational databases.

These models shape what our programming languages can or cannot do at a much deeper layer than mere syntax or even type systems. Mysteriously, I’ve never seen a good explanation of them — you pretty much just have to absorb them by osmosis instead of having them explained to you — and so I’m going to try now. Then I’m going to explain some possible alternatives to the mainstream options and why they might be interesting."

'via Blog this'