Go 1.6 is Released - <AUTHOR> https://blog.golang.org/go1.6 <comment><USER2> Go checks a lot of boxes for _my_ ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes.

EDIT: I must highlight the point about checking lot of boxes. In many discussions about features of programming languages, we get responses like, "language Y does that too. Why not choose that language?" Well, because we don't pick languages for one specific feature. We pick them for the combination of features.

<comment><USER3> Java SE and a fat jar... checks all the boxes and has generics and superior tooling.

I still don't get the Go love.

<comment><USER4> I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer.

That being said, if I were starting a web service as a business today, it would be _very_ hard to persuade me to not choose Java. It's simply the best platform from a business perspective. For better or worse, CS departments across the US produce Java programmers more than anything else. This makes it very easy to hire Java developers. Java has stability, Java has concurrency, Java has hot reloading, Java has a good track record, Java scales, Java has really nice functional programming support, and Java is _very_ popular with the everyday programmer. It Java has so many benefits outside of it's technical or philosophical specifications, that it's almost an obvious choice to me for web.

What's funny is that Erlang _is_ the ideal platform for me from an idealist perspective, but I don't think I have the luck or experience it takes to successfully start an internet company with Erlang.

<comment><USER5> > The mental image of a huge ram sucking IDE with code completion for > frameworks is simply incompatible with

> what I would consider the ideal creative process for me as programmer.

Java has long been my primary professional language, and over the past few years Go has taken on a strong secondary niche at my job. I'm big fan of both, and tend to play Switzerland in arguments between them.

That being said, the best Go IDE out there right now is the official Go plugin for IntelliJ... which again, happens to be the best Java IDE out there. If you are doing modern software development in ANY language, then you are probably traveling one of three paths:

(1) Using an IDE based on JetBrains or Eclipse.

(2) Using a variant of Microsoft Visual Studio, which is about an order of magnitude more bloated than #1.

(3) Using a plain text editor, which for a typesafe language is a bit daft.

<comment><USER6> What does the Go plugin for IntelliJ offer that Go plugins for Emacs don't? My setup right now has live error checking (highlights errors as they occur), gofmt on save, safe refactoring via gorename, jump-to-definition, proper autocomplete, and Go Oracle integration, for e.g. finding all callers of a method. Due to being Emacs it also has much better support for Vim keybindings via Evil mode.

<comment><USER7> Debugging, cross-platform, integration with a lot of other languages, and databases, local history, out of the box configuration for everything you've just mention (including the Vim key working mode, via a plugin) so that people don't spend time in doing all of that and so much more :)

<comment><USER6> In what way is IntelliJ more cross-platform than Emacs?

<comment><USER8> It's written in Java ;)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> The reason I love Go is that every time I pull it out, I write a small amount of it and it runs beautifully. For example my company has a critical micro- service implemented in ~300 lines of Go, it's been running for six months now without a single hiccup, highly performant, very sexy.

The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL.

The point to take away here is that Go, more so then many other languages IMO, has its strengths and weaknesses. If you use Go in one of it's weaker use- cases you're gonna have a bad time. If you use Go for one of it's strengths you're gonna have a great time.

See you guys and gals in n weeks when we need to rehash the pros and cons of Golang again.

<comment><USER10> > The reason I will almost never use Go for web apps is because interaction > with databases is limited > but it's a huge drop in efficiency to spin my > own SQL.

Sorry, I have to disagree. I come from PHP, where when you sneeze an ORM appears. I actually am a DBA also. I am very familiar with SQL and I love writing out raw SQL.

I don't see this as a limiting feature. It doesn't affect me at all.

There are ORMs for Go as well. But I don't know how good they are. YMMV!

Last point. I have shipped into production a web app using GIN framework. I ported from PHP to Go. I didn't feel I was losing anything.

Go is amazing. It hasn't let me down yet. I doubt it will.

<comment><USER11> What are these ORMs you are speaking of? Only usable ORM i've seen for PHP is Doctrine.

<comment><USER12> Any framework has their own. Yii implements active record, I've been working with that for a few years now and I really love the paradigm.

</comment></comment></comment></comment><comment><USER13> There is a Go AMA on reddit for the next 24 hours.

[https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...](https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/)

<comment><USER14> OK Go are also doing a reddit AMA!

[https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_w...](https://www.reddit.com/r/IAmA/comments/46asrt/we_are_ok_go_were_here_to_talk_reddit_so_ask_us/)

</comment></comment><comment><USER15> I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away.

Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.)

Semver and pinning versions has always just _made sense_ to me. I can easily adopt new features and fixes automatically without worrying about things breaking.

How does the community feel this far along?

<comment><USER16> > Is there a reason why one of these hasn't emerged/been adopted by the > community?

Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in?

Collection types have the same problem. You basically need to put some collections in a blessed core library, otherwise it's virtually impossible to reliably share code. Any function that wants to return a list ends up having to pick one of N list implementations and which ever one they pick means their library is hard for users of the other N-1 lists to consume.

The Go team hasn't blessed a package manager, I think, because it's not that relevant to them: they mostly live within Google's own infrastructure which obviates the need for something like version management. They probably don't feel the pain acutely and/or might not have the expertise to design one that would work well outside Google.

<comment><USER17> Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a language to consider a solution worthy of blessing when it doesn't interop with the one my platform was already using or even the ones other languages have.

<comment><USER16> > Use the platform's blessed solution (rpm or dpkg).

Most languages are cross-platform. No language maintainer is going to say, "sorry, Windows, Mac, or <random Linux distro> user, you don't get to use our language."

Likewise, you can't require every package maintainer to just publish their package to every single OS and distro's package repository every time they want to release a new version. Well, you _can_ , you just want have any users if you do.

<comment><USER18> But it makes sense if half the configuration (or what not you expect from a package) is platform specific, like where do the libraries and resources live, does pip know about the windows registry? I doubt it.

</comment></comment></comment></comment></comment><comment><USER19> I can't wait to see what's new in 1.6! I really had a pleasure working with Go for my senior project last year. If I need to write either a server (HTTP or TCP/UDP), or a client application that must be easy to build and distribute, Go is my first choice.

What Go is lacking at this moment in my opinion is:

1) A comprehensive and mature web framework. Play w/ Scala is my go-to choice now, with Django a very close second.

2) A decent cross-platform GUI toolkit; heck, I'd settle with Qt and/or .NET bindings for Go. The power of Go is statically linked binaries, and I think the area of desktop applications will be easy to target if a good solution emerges.

<comment><USER20> Why GUI though? Go shines for servers, but I would never want to write a desktop application with it though. Especially if I could do it in C#.

<comment><USER19> The way I see it:

1) Go produces 100% portable code. I absolutely suffered doing the same for a very basic C++ program that used C++11's std::regex. Compiled fine on clang-3.5 on OS X, fails on clang on Linux. It took me hours of searching online to find and install the exact version of GCC that actually fills in std::regex instead of just keeping it empty. Trust me, there are some versions that do that! No errors during compilation, but still doesn't run.

2) Statically compiled binaries. I can be confident that the absence of some essential library from the user's end won't break my app.

3) Cross-platform, especially with something like Qt. Write once, compile for each OS, then run - done!

<comment><USER21> Go programs can link the Qt library, specifically the GUI components, statically? ... it produces one output binary per target OS?

<comment><USER19> I have not tried Qt with Go to be honest, but in general yes compiled Go code produces a single statically linked binary on the target OS.

<comment><USER22> You can't currently link to Qt statically though. (And holy smokes, that would be a huge binary if it did, just libQt5Widgets.so links to 49 other libraries, everyting from X11 libs to libbz2 to opengl)

</comment></comment></comment></comment></comment></comment><comment><USER23> I've been writing some gocode recently and huge chunk of code is

 _if err != nil ..._

I know you can do if ; err!=nil but that not that much better and you end up in deeply nested if blocks.

i have to mentally block out err !=nil to read any gocode linearly. How is this acceptable, I don't get it.

[https://blog.golang.org/errors-are-values](https://blog.golang.org/errors- are-values)

 _We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two_

This seems false from my experience, def way more than 1 or 2 instances per page.

<comment><USER24> Hard to say without specifics, but my experience writing server code in, say, Python, was, I ended up wanting to handle errors in the best possible way, so my code turned into:

        try:
            x := blah()
        except Foo:
            yadadad

which is worse (IMO) than

        x, err := blah()
        if err != nil {
            yadada
        }

Besides the extra syntactic clumsiness, it was really hard to know what was going to throw exceptions, and which exceptions, and when. Frequently I would get bugs from unexpectedly thrown exceptions.

You said "I have to mentally block out err != nil to read...code" \-- for me, the error handling code _is_ code, code I want to pay just as much attention to as the non-error path.

So for that reason I really like Go error handling.

For a client-side script or something, maybe this isn't true; feel free to use log.Fatal or panic if that makes sense for your use case.

<comment><USER25> > for me, the error handling code is code, code I want to pay just as much > attention to as the non-error path.

You likely want to pay as much attention as required to make things work, but the purpose of your code isn't to generate errors -- errors are what get in the way of the actual purpose of your code.

For people who want to get an overview of what some code does, the error code is interesting only after you understand the actual purpose, and sprinkling the error code throughout the code that describe the purpose of the program causes distraction.

<comment><USER24> A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll reopen the app and try again/rerun the script'), but I think not so reasonable for server-side code..

There's element of personal preference here.

The longer I program the more I favor systems and styles that minimize unexpected problems; explicit error handling is very much in that vein.

Another complication is that the word "error" actually encompasses two very different kinds of situations:

(1) expected-but-non optimal external conditions (there's no file at that path, the tcp connection got closed) and (2) unexpected conditions caused by a bug (array index out of bounds, the regular expression typed into the code is invalid).

Handling (1) gracefully is very much part of the actual purpose of your code: files WILL be missing sometimes, network connections WILL die, so it behooves you and your program to think about these situations as first class.

(2) is not part of the purpose of your program, it's an error IN your program. These are best handled by crashing/exceptions/panic.

A lot of languages mix the handling of (1) and (2), e.g. Python and some styles of C++, which use exceptions for everything. Go uses explicit error returns for (1) and panics for (2), which feels right to me.

<comment><USER25> > A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll > reopen the app and try again/rerun the script'), but I think not so > reasonable for server-side code..

This seems like a response to something that wasn't my comment. I even went out of my way to state what I thought might be obvious: "pay as much attention as required to make things work".

 _Handling errors is a given in this thread._ The question was how to represent that in the structure of the program.

> There's element of personal preference here.

I agree that there's some of that, but if you accept that the main purpose of programming language syntax is to ease reading, writing, and understanding programs, then preference only matters to the extent you can know it, and most of us can assume that we do not know the preferences of the people reading and trying to understand our code. Given that, we must try to use somewhat more objective measures.

When reading code, is it more useful to get a broad overview of the algorithm, or more useful to dive into every possible branch? The answer to this won't always be the same, but for a given type of code it will likely lean heavily toward either breadth-first or toward depth-first readings, which correspond fairly closely to whether error handling is done locally at the site of the error. Further, I think most programs will benefit more from a breadth-first organization, such that errors are better handled (syntactically) in a way that doesn't interrupt the process of understanding what the code is supposed to do.

Go has a lot of things I like, but the difficulty of laying out a clear "do this, then this, then this, then that" is not one. Either you end up with "do this (or handle the error from trying to do that by doing this other thing), then this (unless there's an error here, in which case...)", or you abuse panic, or explicitly ignore errors. If you're in this situation, then the first is the best of a bad lot, but unless you're doing some very finicky, low-level code, it would be nicer to be able to handle errors outside of the purposeful flow of the application.

I agree that having a distinction between different kinds of errors is nice, but errors of type (1) are not the purpose of your code. They're problems that prevent your code from fulfilling its purpose. That's a whole different conversation, though. :/

<comment><USER26> > errors of type (1) are not the purpose of your code. They're problems that > prevent your code from fulfilling its purpose.

I don't really agree with that. In a module that checks whether a user has the right credentials to perform a given task, for instance by checking the used IP is correct and a correct password is given within 3 attempts (or else the account is blocked), dealing with errors (checking password is valid, checking IP is valid, checking account is not blocked, blocking it if needed) _is_ the purpose of the module.

This is the same with any kind of automaton. Knowing when you go into an error state and how you get out of it is part of the problem you deal with.

</comment></comment></comment></comment></comment></comment><comment><USER20> I just recently started with go, but I love how simple (apart from horrible $GOPATH) and effective that is.

Still can't get over the moment I realized that in order to deploy my web server on an empty virtual box all I had to so was to build and upload. After all the languages and frameworks that required endless customization and setting up it was a true eureka moment.

<comment><USER27> What is horrible about $GOPATH?

<comment><USER20> The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely.

For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is another discussion). $GOPATH forces me, therefore, to put a client project in the $GOPATH tree, and this just feels ugly.

Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.

<comment><USER27> I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.

<comment><USER20> > It also isn't clear to me how one might have multiple copies of the same > project.

A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate.

For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same project for different platforms, you still have the original PSD textures in source control, and they are automatically exported to relevant graphic formats when you switch between different platforms. However, this generation takes a LONG time on different projects, and you usually have several copies of the project on your hard drive, each with a different platform selected.

git even introduced a feature that is usable precisely for that scenario, worktree.

<comment><USER27> Sorry, I should have phrased this a little better. What I meant to say was that I almost always have multiple copies of the code that I am actively working on. And if Go has restrictions on where you can place your source tree, then it complicates the ability to have multiple copies of it.

</comment></comment></comment></comment></comment></comment><comment><USER28> Can someone give a decent explanation of the following:

1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program.

2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program.

3) Is there a way to tell from the binary that the program was written in Go?

Trying to figure this out for my Sys Admin dealing with Vendors role.

<comment><USER29> 3) A compiled Go binary contains the import paths of all used libraries plus all variable names that they are using. Also the header of the binary contains a string like "Go" followed by a hash. If you open a binary in a Hex Editor you will see it yourself.

<comment><USER28> So I should be able to write a program or one already exists to check if its a Go program and what its dependencies are.

</comment></comment></comment><comment><USER30> Read the debate with Go vs Java here with interest. I'd like to add a point I think is missed by the Java crowd in favor of Go.

Complexity isn't free. Java might have and abundance of tools, IDE's, language features etc, but you can't claim that matching up every Go feature or tool with something superior found among the huge Java universe makes Java superior in every way.

I find that there is an unfair assumption being used by the Java advocates, here which is that every software developer has a deep knowledge of Java.

As one of those people who can certainly write Java code, but who is not familiar with the Java eco system and has not spend a lot of time with I must say that Go to me is a clear winner.

My exposure to professional Java development has been quite frustrating compared to writing Go code. Every Java project I have gotten has used some different built tool: Ant, Maven or Gradle. They have also all seem to use different IDE's. The complexity of each of these tools is staggering. Considerable time has to be spend learning these tools.

Go in comparison is laughably simple. You can get productive in less than a week without ever having used the dam thing. The tools and the libraries are very quick to get into. In fact I find Go code so easy to read that although I am an iOS developer by trade, I frequently read Go code to understand how various algorithms and network stuff works.

An organization would easily be able to add people to a Go project without much previous exposure to the language. Adding people with limited Java knowledge to a Java project however would be far more expensive. Considerable time would be needed for training.

There is a lot of money to be saved from having a well thought out standard library combined with a simple language with simple well thought out tools.

As a Swift/Objective-C developer, my major gripes with my development process is actually the complexity of the tooling. Both Swift and Objective-C are fairly straightforward languages IMHO. In this regard I greatly envy Go developers although I do enjoy the strong typing and generics in Swift.

</comment><comment><USER31> I fell in love with python because it was clean and easy to work with. Like most developers, I used to use c when I needed a performance boast. Then I got fade up and decided to learn a new language that could give me the feel of python and the performance of c. Two languages from a list of 10 passed the above criteria Go and Rust. Java did not even make the list because I Don't use languages that are owned by evil empire's(Oracle).

I went with Go because it was easy to use and understand. I could read other people's code easily( Even with a large code base, I have never found myself scratching my head trying to figure out my own code does), could set up my workspace in less than a minute and all the text editors I used (sublime, Atom, Vim) supported it. I Don't really care about the fancy IDE's. Just syntax highlighting and code completion is good for me.

I started learning go on September 2015. And I have managed to implement the porter stemmer algorithm and an inverted index in it. Miss generics but LOVE interfaces. The fact that any concrete type that implements method 1 satisfies interface 8 is awesome. You can easily reuse code from different package without changing anything.

</comment><comment><USER32> Release notes are here:

[https://golang.org/doc/go1.6](https://golang.org/doc/go1.6)

Notably new this time is transparent http/2 support and tighter rules for integration with C.

</comment><comment><USER33> Go CSP is minimal and ortongonal, I just wish it did three things:

0\. could lto optimize or link against a shared library to reduce the titanic size of compiled programs and cut down on duplication of instruction. Therue is no practical sense in wasting memory and storage on systems with dynamic linkers: edge cases of including the world for rare situations but YAGNI in real production systems.

1\. could output flat binaries and self-host runtime (panics) for practical kernel development in Go

2\. Generics (both types and immutable constraints), I think C++1z has the right approach to this (and constexpr and constant arrays are nice and are able to provide more hints to the compiler).

I also wonder why Go wasnt developed as an IR compiler / llvm frontend, because it would've levered an existing debug and portability ecosystem with much less work.

<comment><USER34> 0\. It does dynamic linking on most stdlibs (libc, etc)

1\. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly)

2\. Generics would be nice. Who knows, maybe they'll be in 2.0?

Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in golang from the start (so that it could be part of the libs). Also having your own scheduler kind of breaks debugging, you can build go programs with gccgo, but gdb doesn't work because it has no concept of what a "go routine" is. Delve ([https://github.com/derekparker/delve](https://github.com/derekparker/delve)) will eventually fill the hole of the missing debugger, imo.

Edit:

Formatting

<comment><USER35> > 2\. Generics would be nice. Who knows, maybe they'll be in 2.0?

There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.

<comment><USER34> Not that I even care that much, but that's total crap. Compile-time generics, which is what most people seem to be referring to when they say they want generics in Go, are eminently doable. It would not be hard to implement. Runtime generics are probably possible as well.

What are you even basing your assertion on?

Edit:

What do you mean, "there will never be a 2.0"? Do you have a crystal ball?

<comment><USER36> The team has already stated "The language design is done".

<comment> grey-area The issues list has a bunch of breaking changes they've put off to Go2. It won't come soon, but probably at some point they will produce a Go2, if only to fix a few small annoyances and things they got wrong in the stdlib which would otherwise break the Go1 pledge. Of course, that doesn't mean Go2 will introduce lots of huge changes to the language, I doubt very much it would, but it probably will happen sometime.

[https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+l...](https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3AGo2)

As another datapoint, here are the answers of the team to a question on what they dislike about Go1. These are mostly breaking changes which would require a Go2. I don't think anyone is hostile to it long-term, they're just not in a hurry. There is a _huge_ value to developers in not having churn in an ecosystem and breaking changes, I and many others really value that and am pleased they take this approach.

[https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...](https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_the_go_contributors_ask_us_anything/d03s41s)

So I think you've misinterpreted the above statement, it was probably an off hand remark in response to proposals for Go1 which would have radically altered the language (I can find no ref to it on the web, 0 results for that phrase).

<comment><USER36> Update to my reply.

"So… when is Go 2?", Slide 38

"No plans. Maybe never.", Slide 39

[https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMN...](https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMNvpo7ntqteWQfynq9hFTCkhQ/view?slide=id.p&pref=2&pli=1#slide=id.g118cf9b85c_0_404)

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> Congratulations to the Go team! There are many excellent folks working on the Go language and it's been an absolute joy to work with in my experience.

</comment><comment><USER38> [https://golang.org/doc/go1.6](https://golang.org/doc/go1.6) \- lists the changes

</comment><comment><USER39> Have been using Go since its release, and like the deployment experience, the feeling of solidity of putting together a tight system. The toolchain is great. 1.6 is yet another Solid release in that direction. Thank you all.

However, the _language_ doesn't give me much programming pleasure alas. Since there is plenty of time for Christmas, here's my syntax wish list :)

'?': C's if-then-else operator.

Block-syntax for closures ala Ruby. Unifying blocks and closures makes creating DSLs easy, but doesn't add to cognitive load (no more than using anon funcs)

Pattern matching like Scala, ML, Rust.

Sum types -- (Yeah, I lied. Not just syntax enhancements), or at least discriminated unions. I'd like to see an example (in the FAQ entry on the topic) on why support for it is troublesome.

For 2017 Christmas, \</comment><comment></comment><comment></comment><comment>-

Macros ala Nim.

Systemic support for Goroutines, including detection of conditions where a goroutine would never get scheduled. Erlang-like tools for built-in goroutine insight.

\</comment><comment>

My ideal language would be an intersection of Nim+Go

<comment><USER26> Sum types don't play well with zeroed values by default. What is the zero value of a sum type ?

Pattern matching doesn't work well without sum types.

So don't hold your breath.

</comment></comment><comment><USER40> I upgraded and it broke our app, something to do with the way it handles https has changed, not sure what

<comment><USER13> If it works in Go 1.5.3 but not Go 1.6, definitely consider filing an issue. [https://github.com/golang/go/blob/master/CONTRIBUTING.md](https://github.com/golang/go/blob/master/CONTRIBUTING.md)

</comment></comment><comment><USER41> Not officially. "Go 1.6 is soon (but not yet)." \- commit message from today.

<comment><USER42> I _just_ got this email:

"Hello gophers,

We just released Go 1.6.

You can read the announcement blog post here: [https://blog.golang.org/go1.6](https://blog.golang.org/go1.6)

..."

</comment></comment><comment><USER43> Go has a lot going for it.

That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project:

1\. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pain.

By tinkering, I found that I often had to comment out or uncomment lines, or handle or ignore errors. There was a lot of flipping up to the beginning of the file. I would spend so much time fiddling with the lines that I would at times forget what I was even trying to do.

I might just have memory problems, I acknowledge. :)

However, what would make sense is a go "mode" where it runs in a non-strict way, with what would ordinarily be errors being warnings. A "tinker" or "whirl" mode, so to speak, that softened the requirements so one could get a better sense of what was happening before committing to a design.

An interpreter mode might also be quite valuable, to address this problem and the ones below.

2\. Error propagation - I see the point of errors being returned and the lack of a "throw/catch" style, and its benefit, but I feel it's a lot of typing for marginal gain. I usually end up with an error propagating a set of strings that ultimately conclude as: "Database error: transaction error: processing error: http error: _reason_ ", which is to say: equivalent but less information than a stack trace would give. I see the mandatory error acknowledgement simultaneously as a strength and a waste of time, and I admit being on the fence about it.

3\. The next point I am not on the fence about: Debugging. It is not apparent how to get a stack trace, and the best option looks like including a third party application that generated errors. For the obvious and reasons below, this is a problem.

4\. Package management: This was fussy and could be time-consuming. It is not apparent to me why one needs a GOROOT and a GOPATH. I think Python's virtualenv gets it right, by comparison. A second but related problem is package versions. Maybe I'm missing something, but making sure you get the latest semantically equivalent version (in the semver sense) was not apparent.

5\. Package debugging: If you include a 3rd party package, and it's broken in any way, it's a veritable quagmire to identify and fix the problem. My experience was that the best way to debug a third party package was to block and copy all its bits and then debug it as a local source in your own. Obviously this is bad for a long number of reasons, and I might be missing something, but no more apparent option appeared when I investigated on how to tell what is even happening inside third packages.

6\. Automated testing: I've not seen a test runner that reloads when source files change, particularly one that might be used with goapp from AppEngine, meaning go auto-testing can be quite a bit of patient thumb-twiddling as the binary reloads.

Which is all to say that there are some concerns about developing a larger project in this language, particularly if there is quite a bit of complexity that needs lots of testing or potential debugging and/or inclusion of many third party packages.

I've not reviewed the 1.6 notes, so perhaps these are addressed to some extent there.

In any case, none of the issues above is insurmountable, and overall I give the Go design a lot of credit for experimentation and interesting choices, but the issues I've seen above give me pause before committing a team to the language – for the moment.

<comment><USER37> For (1), I'd highly suggest using 'goimports' (my editor's fmt-on-save uses 'goimports' by default). It will remove and add non-referenced imports as needed. Also, quick prototyping is partially what the underbar (_) notation is meant for in variable assignments.

As for (2), I feel it's more of a consequence of programmers not using error types to its advantage. Since Error is an interface it allows for an absurd amount of flexibility (e.g. bundle up a whole bunch of information into one error and send it back) and typed errors, both of which are excellent for testing and debugging.

As for (3), I usually rely on printing output (github.com/davecgh/gospew is quite useful). To get a stack trace just calling panic() in the offending code area will suffice.

No arguments on (4) - it could be better - but I think support for vendoring is a good step, and the maintainers seem to be taking it slow and getting it right.

On (5) -- if you go get the package it's available in GOPATH and/or it's usually vendored, so you can just go edit it in place (including debugging statements if you need more insight) without needing to know any magic $X_PATH rules -- I see this as a huge advantage. Furthermore, go get-ed code is each in its own version control repo, so sending patches back upstream is (generally) easier than ever.

Anyway, hope I don't seem argumentative (everyone has different tastes), but maybe some of these suggestions might help you a bit with your language peeves.

<comment><USER43> Great feedback, thank you.

On (1) Great suggestion, looks good.

On (2) I'm probably biased by having spent a lot of time with Python and Javascript and bound to some preconceived notions of how one should deal with exceptions, so perhaps I give Go a harder time than I should for my failings and not its. :)

On (4) I hope they get it right; packaging can definitely make-or-break the system.

On (3) and (5) I found these techniques could/did-not work when testing Go App Engine. Editing the third party source had no impact, even after restarting App Engine, re-running tests, and deleting the .a files. I'm sure it's just another trick, but I couldn't find it so I eventually just gave up ... hence it being in my list of concerns.

Thanks for the feedback, I appreciate the suggestions.

Cheers

</comment></comment></comment><comment><USER44> Seen a lot of Erlang mentions in this thread. Is that the native alternative to Go?

Personally, I prefer to write code in a functional manner. While I've always thought Go looked like an amazing platform for programming in general, I haven't been keen on moving to another imperative language.

It seems the landscape for functional alternatives are mainly Scala and Clojure which are both based on the JVM and require a bit of time to learn the tooling. I am not a Java or JVM export, so I haven't been too inspired by this either.

<comment><USER45> > It seems the landscape for functional alternatives are mainly Scala and > Clojure

Cannot talk about functional alternatives without mentioning Haskell. OCaml (when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often abstain from the "O" in Scala) is also an interesting option.

Finally there's Rust, which is besides being a bit more functional also more low-level than Go.

While being fairly young, Frege[1] also deserves a mention. Very similar to Haskell, but on the JVM.

1: [https://github.com/Frege/frege](https://github.com/Frege/frege)

<comment><USER44> Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. Of all the FP languages, this is actually the one I am most tempted by.

I had forgotten about Rust. Are there major projects being used for this yet? I've heard it's picking up quite a bit.

<comment><USER46> > Well, I was tempted to mention Haskell. Problem is, I haven't found a > practical use for it.

That's the same as saying:

Well, I was tempted to mention Go. Problem is, I haven't found a practical use for it.

That is to say, just pick a problem and try to use Haskell to solve it. 90% chance it will fit your niche fine.

</comment></comment></comment></comment><comment><USER47> Rebuilding our integration docker image right now. If all our tests pass I expect to have go 1.6 binaries in production by this evening.

</comment><comment><USER48> I would just love some IDE-debug love and better packaging. More packages I use and more I distribute my files, compilation takes considerably longer. Maybe I do not know, but is there some process to compile some parts before hand and link only the changed resulting binary?

</comment><comment><USER49> Can anybody tell me if you can run Go in Chrome using the NaCL stuff? I remember there was talking of it a few years ago but I don't know if anything ever came of it.

A google seach show that you could build for NaCal in Go 1.3 but only run it in special builds not Chrome itself.

<comment> iso-8859-1 As you can see on [https://github.com/golang/go/wiki/NativeClient](https://github.com/golang/go/wiki/NativeClient) , there is no PNaCl support, which means it is only available in the Chrome Web Store.

<comment><USER49> Thanks for the heads up.

</comment></comment></comment><comment><USER50> There was some discussion leading up to the release about whether to merge the "SSA" branch, which seems to be a refactor that allows for easier compile time optimisations but also slows compile times for the time being.

Does anyone know if that was included in this release?

<comment><USER37> IIRC from the e-mail thread, the idea being discussed was to potentially merge the SSA branch immediately after the release (in order to have as much time as possible to test it), so I'd be surprised to find it in this release. There were concerns about the compiler slowdown but I didn't see the end result of the thread.

</comment></comment><comment><USER51> > Source trees that contain a directory named "vendor" that is not used in > accordance with the new feature will require changes to avoid broken builds

That seems a little bit distasteful.

</comment><comment> kiril-me Do you know any framework using http2 on go lang?

</comment><comment><USER52> Binaries are up but not everything is fully updated yet. Announcement blog post coming shortly.

Edit: Blog post up: [https://blog.golang.org/go1.6](https://blog.golang.org/go1.6) maybe change the article link to that?

<comment><USER53> Ok, we changed from [https://golang.org/dl/#go1.6](https://golang.org/dl/#go1.6) to that.

</comment></comment><comment><USER54> A draft for the 1.6 release notes: [https://tip.golang.org/doc/go1.6](https://tip.golang.org/doc/go1.6)

</comment><comment><USER55> Release notes: [https://golang.org/doc/go1.6](https://golang.org/doc/go1.6)

Mods, maybe change OP link to this?

<comment><USER52> This is the better link target: [https://blog.golang.org/go1.6](https://blog.golang.org/go1.6)

</comment></comment><comment><USER56> Go is great, but I wish they would add terany operator support.

<comment><USER57> They won't. The Go authors value simplicity. Many people dislike ternary syntax and find it hard to read. Go errs on the side of verbosity and readability. It is sort of the opposite of Perl in that respect.

<comment><USER56> Which is more simple, an if/else block or a terany operator?

if/else:

if i == 0 {

       return "foo"

} else {

       return "bar"

}

terany:

return i == 0 ? "foo" : "bar"</comment></comment></comment>


We'll finally see that the Fed has done nothing to help Main Street - <AUTHOR> http://qz.com/161080

<comment><USER2> no kidding..it helped make me richer in terms of rising stock prices, web 2.0 valuations, and real estate but didn't help mainstreet because it was never intended to. fighting unemployment is the excuse the fed uses to sell the program and the media buys it.</comment>


Why programmers are not paid in proportion to their productivity (2009) - <AUTHOR> http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to-their-productivity <comment><USER3> I think John missed one.

The other thing I've seen happen is that the more productive programmers are asked to do the more complicated things. So they'd be the ones creating a javascript drag-drop widgets framework while the less capable were stitching together CRUD apps with a bit of business logic in the backend.

This then looks like they're both delivering products, the CRUD app may even earn a lot more money for the business in the short term too.

I've even seen this kind of skill discrepancy in call centres when I temped as a student, this isn't restricted to the programming field. There's always a couple of people who knew how to fix actual problems rather than just enter payment details, they'd always be handed the troublesome clients but rarely got paid more.

I ended up as one of these myself, but none of us ever complained about being paid the same as Bob the lazy call avoider because it made our jobs far more interesting and satisfying.

In the end I guess part of being a high performer is that you know you're going to get the jobs that interest you and that in truth would just frustrate and demoralize your colleagues. It's not always about the pay.

<comment><USER4> A good manager in a software company should have a decent grasp of project complexity and output quality of his subordinates.

The examples listed seem to appear at companies that have in-house developers, but don't really think of IT as an area they should focus on. Similarly, I often found my ex ad-agency co-workers have trouble understanding why I have to browse blogs/manuals, take time to think things through, sketch graphs and sometimes just start over instead of refactoring.

Really, software managers should have no trouble noticing a 10:1 skill difference between devs.

<comment><USER5> There are very few good managers, and when you think about it very few programmers work in software companies. Instead they work for trading firms, utilities, banks, government agencies, etc.

When the business of the company isn't software, there is a good chance that the manager won't be a software developer. The criteria the developer is judged by will have nothing to do with the complexity of the software or the time it takes to create. Instead, their work will be judged and compensated by the value it delivers to the organization. _Even if it's crappy software._

<comment><USER6> > The criteria the developer is judged by will have nothing to do with the > complexity of the software or the time it takes to create. Instead, their > work will be judged and compensated by the value it delivers to the > organization.

You say that like it's different, or should be, at a software company.

I disagree. I think that all work for an organization should be judged and compensated by the value said work delivers to said organization, regardless of the organization type, regardless of the work type.

> Even if it's crappy software.

Surely you're not suggesting that crappy software is always wrong/bad.

Good software is often more expensive than crappy software. That added expense doesn't necessarily produce more value.

Good programmers know that they're trying to maximize benefits-costs, not maximize the former, not minimize the latter.

Worse can be better.

</comment></comment></comment></comment><comment><USER7> Why haven't I seen the following comment here?

        patio11  10 minutes ago  |  link

        Programmers are paid in proportion to the value they create.
        If you want to make more money, work on stuff that makes money,
        then ask for that raise.

Is there really any other explanation? Think about this like patio11 or Greenspun: work on stuff that makes money/value for the business, go talk to your managers, point to the thing you created and say "this generated $X in revenue for us. I'd like to partake in some of that revenue."

Then head out to dinner or happy hour and enjoy your raise, or jump ship if the company laughs at you.

Isn't this how the labor market for programmers works? If not, why aren't we making this happen?

<comment><USER8> That isn't exactly how it works --

It is a valid argument for raises, especially early in your career. But at some point, you are no longer selling your personal value to your boss - <USER2> are competing with other programmers who are willing to give the same value for a lower salary.

To get past that point, you need to have specialized business knowledge so that outside programmers cannot compete with you.

The trick to getting very high salaries is to decrease the pool of competitors for work, by increasing specialized knowledge above and beyond your coding skills.

</comment></comment><comment><USER9> Isn't the obvious, uncomfortable answer, that management wants to maximize profitability? It's almost the definition of their job to find these 100x productivity programmers and pay them the 1x salary. Also, note that when you have an entire team of 100x programmers, and you are only paying them 2x or 3x the salary of the 1x programmer, the manager has succeeded well in their goal - not only has the pay-me-more-for-my-skill argument disappeared (they are all the same 100x skill level) but you are extracting the massive amount of excess productivity into profitability. bottom line is that if you really are a 100x programmer, it is difficult to fully capitalize on that skill

<comment><USER10> >if you really are a 100x programmer, it is difficult to fully capitalize on that skill

Only if you work at xyz corp!

</comment></comment><comment><USER11> The best part of the article:

 _The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says "Hmm. I think I've seen something like this before."_

<comment><USER12> Seems in line with Rich Hickey's "Hammock Driven Development" (Here if you haven't seen his talk: <http://blip.tv/clojure/hammock-driven- development-4475586> )

</comment></comment><comment><USER13> I disagree with all the reasons he listed... because this is true of all careers, not just programming. I think it has more to do with our ideas about pay more than anything else.

Quite simply put, in almost all professions you're paid for being there for 9-5. If you show up and do your work poorly or not at all, you might get fired. If you do well, you will get a small raise. So to a small extent productivity is correlated. But the salaries aren't proportional to productivity; the biggest predictor of salary is if you're fulltime. You're getting paid for your time, not what you're producing.

</comment><comment><USER14> Programming at the level of HN readers isn't a science, it's a creative art. You buy artwork based on it's value to you as a finished product. Very few people commission art from artists other than those who are very well known.

Conclusion - sell finished works of art, not your time. Effectively, SHIP A PRODUCT PEOPLE WANT.

<comment><USER15> "Programming at the level of HN readers isn't a science, it's a creative art."

Can we please stop circle jerking like this? I have no reason to believe that there aren't a bunch of idiots on here, just as most anywhere else.

<comment><USER16> Can we please stop using the phrase "circle jerk" to demean people we disagree with? Just because there may be "a bunch of idiots on here" doesn't make it Reddit.

<comment><USER15> I don't 'disagree' with him, one 'disagrees' with opinions, and I don't waste my time on that - opinions are like assholes, everyone's got one and most of them stink. There was a factual claim being made, that somehow people who read some specific pages on the internet (the HN pages) are smarter than others, a claim arising from snobbery and self-aggrandizement; one of a false duality, too, like your 'doesn't make it Reddit'.

<comment><USER16> Whatever. Just get your damn ad hominems out of here.

<comment><USER15> Did you even read what I said? It's _not an ad hominem_.

<comment><USER16> Yes, it is. "Circle jerk" is a term used to denigrate someone who gives (in _your_ view) unnecessarily effusive praise by comparing it to an adolescent sexual behavior. If you feel the praise is unwarranted, you're welcome to express that feeling -- and if you have evidence to support this, you're welcome to present it -- without the insult.

<comment><USER15> It's not an 'in my view', it's objectively wrong to outright assume that somehow people who read some site are better than others. There is no reasonable way to interpret the original comment in any other way.

Furthermore, it's not an ad hominem because an ad hominem is an argument that is being made by discrediting that argument not on its merits but on an unrelated other characteristic of whoever made it. I'm not doing that in any way - the use of 'circle jerk' in this context is perfectly warranted as a way to express disapproval of the poster's myopic thinking methods (or rather, myopic world view based on lack of thinking).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I think there's a simple explanation for this: asymmetry of information. While the programmer knows that they are a 10x programmer, the company hiring them does not. Interviews, resumes, and referrals only provide a limited set of information, and surely not enough to boost the company's perception of you up to the 10x range. So that's why salaries are much more compressed than skill.

The standard economic solution for these types of markets is to offer a "warranty", the idea being that the better product will be able to outcompete on "warranty". For programmers that might mean agreeing to a contract where you get paid, say, $300k, but if after X time you aren't performing well enough then you have to pay back most of it. Actually this is sort of what happens already with equity.

</comment><comment><USER18> If you have two programmers, and one is "10x more productive" than the other in that he knows when to reuse or adapt other code, but there is a problem that actually does require writing code, which one will put out a more correct, reliable solution faster? I would guess that it would be the 10x more productive programmer, because he/she doesn't just know when to reuse or adapt other code, but also when to reuse or adapt algorithms, architectures, etc. or "solutions" generally.

I'm annoyed that Cook is _still_ undervaluing these programmers in this article by not explicitly mentioning solutions in general, but only "reusing code", which is just a special case of reusing solutions.

<comment><USER19> The '10x more productive' in this article was referring to people who reuse and adapt, you seem to have it backwards. You are infinitely more productive if you realize the problem is already solved. Not only is it faster, but it also isn't as likely to suffer from bugs.

But I also think you are assigning to him a slightly different opinion than I understood it. It's not just 'This would be a good time to use Excel!" or "This would be a good time to use Library X!", it's "This codebase already has something that is slightly different; we can probably generalize that slightly and save a lot of headaches". He _is_ talking about people who write code every day, but people who are better able to apply existing frameworks to the new problem instead of banging out something from scratch.

Also with regards to your "still", this article is not new.

<comment><USER18> No, I don't have it backwards and that is indeed the kind of programmer he was talking about. I am only saying that the _"This codebase already has something that is slightly different; we can probably generalize that slightly and save a lot of headaches"_ situation is just a _special case_ of better, more adaptive problem solving that doesn't necessarily rely on the "codebase already [having] something that is slightly different".

And I know the article is not new, the point of "still" is that the article seeks to address the undervaluation of these programmers, yet doesn't give them their full due. This is because most (if not all) of the same programmers who practice that special case of efficient problem solving _also_ are capable of more generalized forms of efficient problem solving, and Cook doesn't mention this.

<comment><USER19> > are capable of more generalized forms of efficient problem solving

I still don't understand what you are trying to say. The entire point of the article is that "people who are capable of the more generalized form of efficient problem solving are more valuable". He's not saying that you never have to sit down and get your hands dirty and write something from scratch, or that the most efficient people never do that.

You are agreeing with what he wrote and acting like he said the opposite.

</comment></comment></comment></comment><comment><USER20> A corollary of this article is that experience is also undervalued. It is experience and the ability to reflect on it intelligently that prevents people from making a mess. Its that mess that is killing productivity in most shops.

<comment><USER21> Maybe, but if you paid the juniors appropriately on that scale they'd never get into the industry and if you paid the seniors on that scale the business couldn't afford them.

</comment></comment><comment><USER22> I think we should address 2 questions first before we can answer this. Why do some programmers think they are 10x or 100x more productive than others? Is it a myth or is it for real? Give some concrete examples of 10x productivity for a start.

<comment> wes-exp The 10:1 productivity gap is well established in the academic literature for software engineering.

There are not many concrete quantitative statements one can make about the profession, but this is one of them.

<comment><USER23> Do you have any references for this, my good man? I don't mean to question your comment; I want to learn more about how this has been established and the nature of it.

<comment><USER24> I don't have any references to academic research, but my own experience interviewing people supports the claim. When presented with a simple coding problem, some people just breeze through it, others take most of the interview to finish it, and some candidates just can't solve it at all.

To the extent to which coding on a whiteboard is an indicator of real-world productivity, there definitely seems to be at least 5x difference.

</comment></comment></comment></comment><comment><USER25> This article and general theme are based on an invalid premise. Many of the most productive programmers are, in fact paid in proportion to their productivity.

Such people are likely to found startups or join at an early stage or they're likely to work at places like Google that issue large stock grants to many of their most productive programmers. Those who don't are more interested in stability than money.

Large non-software companies and governments fail to compensate their most productive programmers proportionally because they have difficulty identifying the benefits they're getting or simply don't value them all that highly. Most of us consider it obvious that such organizations aren't the most desirable work environment for programmers.

</comment><comment><USER26> Because no one has found a good way to improve the quality of information in the job market for programmers (yet).

It's still very hard for an employer to detect skill, and for a job seeker to select good potential employers.

Could be an idea for a very useful startup :)

</comment><comment><USER27> If he can't say that it's easy to measure whether someone is 10x more productive than the average programmer then how can he say they are 10x more effective? Also I work at 200 person game company and there is no programmer that even performs close to that level. Maybe 2 to 3x the average for absolutely exceptional programmers. But your average would have to be pretty fucking crappy to get anything more than that (and even very talented programmers aren't more than 2x the average).

<comment><USER28> Productivity in the shortest time scales is hard to measure.

But, when someone spends a few days and makes an optimization that literally prevents well over 1 million dollars of new hardware from being purchased that's real value. (This actually happened.) Create that type of value a few times in 5 years and yes someone can really create 10x the value of the average programmer.

PS: Not a programming example but <http://en.wikipedia.org/wiki/Polymerase_chain_reaction> is one of the more extreme examples. Kary Mullis literally created billions of dollars of value paying him 10x what the average researcher makes for 40 years and it's still a net win.

</comment></comment><comment><USER29> Why programmers are not paid in proportion to their productivity? Because they procrastinate the other 50% of the time! (Obviously, it is a joke. But ironically, we're discussing that on HN...)

<comment><USER30> Or they procrastinate and take it easy because there is an upper limit to compensation per unit of time & effort. If I am truly 10x more productive, that means I should be able to keep a steady paycheck rolling in with 4 hours a week!

</comment></comment><comment><USER31> The most productive programmers are the ones who can solve the problem without writing any code at all.

</comment><comment><USER32> <http://www.readability.com/articles/uuek7ysi>

</comment><comment><USER33> Dead on.

What makes a good programmer good isn't the code they write, it's the code they don't.

</comment><comment><USER34> The article is from 2009.

<comment><USER35> But, still a good article.

</comment></comment><comment><USER36> I noticed something similar, though not as a programmer.

I tested videogames one summer, where it was my job to locate and report bugs. It was soon apparent that there was huge variation in productivity: some people submitted more and better bugs, in better written reports, than others.

Most people were hired as independent contractors through an outside company. A select few would be hired by the actual game company, and kept on through the season. Was it the most productive who were kept on? No. It was the people who put in the most overtime hours, and made themselves available when the company asked.

Call me an ignorant youth, but it seemed like, if they wanted to, they could raise salaries, fire the bottom X%, and hire some more talented QA testers, and still come out ahead.

Cook's explanation doesn't really explain this scenario, but I have a feeling the answer is similar, for both the QA tester and the programmer.

My theory: management simply doesn't care, and doesn't need to. If you were to walk out, they could easily get someone else at the exact same pay-grade. It's only when your value to the company is crystal clear, and you are clearly better than the competition, and that there's a viable threat that you will leave somewhere else and actually get better pay, that a company will pay you accordingly.

After all, economics doesn't say you get paid what you're worth. It says you get paid the market clearing wage. You might be creating $200 of value per hour for your employer, but if there are tons of people ready to work for $10 an hour and are just as productive, then you will get paid $10 an hour.

This is more conjecture, but I think for things to change, for people to be paid according to their productivity, two critical pieces of information are essential:

1\. Exactly how productive you are, relative to your peers. 2\. Exactly how much people of varying abilities make.

The problem is, for #1, the metrics are bad if at all existent. For #2, there's a huge taboo against telling people what you make, which ultimately helps employers keep wages lower.

I think my QA testing situation would have been different if say, the men in charge took some pride in it, and only hired great testers. They didn't, they were just filling slots, so the QA on the QA testers themselves was pretty shoddy.

<comment><USER37> "Call me an ignorant youth, but it seemed like, if they wanted to, they could raise salaries, fire the bottom X%, and hire some more talented QA testers, and still come out ahead."

Not ignorant at all; this is a very insightful observation. I've seen the same thing from the programming side. Unfortunately, an unskilled programmer can create more and longer-lasting damage than an unskilled QA tester -- some code sticks around for decades and has layers and layers of new code built on top of it. Thus, bad programmers can drag down other programmers' productivity long after they've left the project. So the advantage of replacing a lot of bad programmers with a handful of good ones who are better paid could be even greater.

Not to mention that a smaller group has much less communication overhead than a larger group (as described in The Mythical Man Month).</comment></comment>


Ask HN: Beta Testers - <AUTHOR>

Need some more beta testers. Any sites where startup founders reciprocate beta testing each others site.  Meaning, I use and test his site and he uses and tests mine. <comment><USER2> Check out <http://www.criticue.com/> \- this a new site. Here is the HN thread about it <http://www.criticue.com/>

</comment><comment><AUTHOR> Thanks, I did see that site. I was looking for something that would allow involved interaction for testing/using rather than aesthetics.

<comment><USER3> Http://www.betapunch.com is nice.</comment></comment>


Rewrite Linux Kernel in Rust? - <AUTHOR> https://dominuscarnufex.github.io/cours/rs-kernel/en.html <comment><USER2> Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome.

Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it being mostly theoretical.

<comment><USER3> Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is [https://github.com/ckkashyap/nimxv6](https://github.com/ckkashyap/nimxv6) which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things too.

<comment><USER4> Do you get anything with him? I was under the impression dereference safety wasn't a priority.

<comment><USER3> Nim or Rust might be appropriate depending on the project. To me the idea of replacing C with either of them comes down to a value-sell of how much you value Rust's safety guarantees and whether you're willing to make the investment of learning to use it or if you're just going to wrap everything in unsafe{}. Considering you're talking to C programmers, I don't think they value that safety very much. If they did, at least compared to other values, they'd have moved to a GC language like Java long ago, or at least a C++-subset-with-rules. So Nim has a lot of nice features that they might like and expect from modern higher level languages, a lot you can use even if you alloc() everywhere and avoid the GC, which you can do because it has an optional and implementation-swappable GC. And it's not like Nim is just as unsafe as C if you don't use the GC, the compiler stops you from shooting yourself in the foot for a lot of things plus there are some good (tunable) defaults on runtime behavior. Finally the ramp-up time to get productive in Nim, and ongoing development effort, is probably less than Rust, which will help the sell too.

<comment><USER5> pardon my ignorance, but wasn't "safe-and-performant" impossible before rust?

Isn't choosing a GC-language some trading off performance for safety?

<comment><USER3> It's a common misconception that GC languages must be slower than languages without one. Where that misconception probably comes from is that it's pretty easy to write performant code in C, and hard to write terribly slow code, whereas in languages with GC in some instances you can do as good or better but it's often harder. These days if you're comparing Java and C++, it's not unusual for the Java code to be faster. The bigger tradeoff for GC is more in the loss of determinism, some applications (like games) can't tolerate a random stop-the-world collection for n ms. This can be mitigated by pauseless/stoppable/real-time-guarantees GC implementations though so if your language lets you swap the GC you have options around this. (For something like a game, naive malloc/free aren't enough either. You're going to have to manage your memory intelligently regardless of if you have a GC or not.)

As for Nim all I can say is run some benchmarks on C, Rust, and Nim. Compare the ease of implementation. Compare the relative safeties beyond memory ownership safety. Nim does very well.

<comment><USER6> You mentioned the determinism tradeoff, which is one the gamedev community talks about endlessly. I'm no low-level expert, but my understanding is that determinism isn't all you lose.

My understanding is that the big tradeoff is against RAM usage. You can have relatively-low-RAM-usage JVM programs, and you can have fast JVM programs, but you usually cannot have both. Keeping the total cost of GC low is done by amortizing the cost over more run-time, which means running less GC often, which means accumulating more garbage between runs. I mean, compared to the insanity that is an Electron app or something, it's no big deal, but this means that the pre-Rust tradeoff is something like "Memory safety, small memory footprint, fast running time: choose two". (I want to emphasize that I'm repeating hearsay, not reporting from my own knowledge.)

Also, it's probably a minor point, but JVM startup time is terrible compared to a native binary. Many many programs don't care about this, but some do.

Code size (not counting the JVM) might well be improved, but if this is the only JVM code on this machine and you need to pay that cost, that's a tradeoff too.

<comment><USER3> You're right that total memory can be a tradeoff since any GC will necessarily have some space overhead, the question is how much, and whether you can accept some time tradeoff in exchange for less space. So again it all really depends on the GC implementation (or implementations, e.g. standard Java can swap implementations too). Remember that Java was originally designed to run on embedded systems, Lisp has been used on very tiny hardware, and GC theory has been developing from at least the 60s. Memory is plentiful compared to those days.

My go-to reference when getting into GCs is [http://gchandbook.org/](http://gchandbook.org/) and it covers all this in the beginning. One old study tried a particular GC algorithm with Java and some various program benchmarks and found to match perfect manual allocation time (which will be better than in practice) you'll need about 5x the minimum memory, 3x gives you 17% overhead. I think anywhere from 1.5x to 3x is normal in practice since it depends on the application itself. There are tradeoffs everywhere and it's great Rust offers another one.

I thought JVM startup time was a dead horse. :) Sure native beats it, so does Python, but not by much these days.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it?

Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust. Even for a browser, Rust is only a band-aid. The amount of logical errors and security holes in something as complex as a modern web-browser is more than enough of an attack surface. No need for a rouge pointer to weird memory.

What is MUCH more viable though is a project to compartmentalize the Linux Kernel into HVMs. I forgot the name but there are efforts to put nearly everything into its own HVM. Which means if the printer driver goes nuts, it can't really do anything to your system except not print anymore. If your graphics driver goes nuts, well then you won't see anything... And so on.

This means, almost no code rewrites and still MUCH higher protection than RUST. Rust does not compartmentalize. If any of your system components is fucked, your whole system is still fucked. That is why it's pointless to rewrite a kernel because of a language. You need to compartmentalize it...

Look at QubesOS for an early user-space effort. Would be nice to have a Qubes- Kernel too.

<comment><USER8> You're referring to microkernel/nanokernel architectures.

Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring.

Linus is also noted in this thread as not being interested in security issues.

I do agree with you about Rust not solving the hardware problem.

<comment><USER7> Yes it also makes sense. Because no matter what you do, it is unlikely that your are able to compartmentalize something so critical and raw as a device driver. If that one is fucked, the reason is likely that your system is already compromised. It was just an example of what WOULD be more viable and effective than rewriting it in Rust.

I still think that QubesOS is taking the right approach. Initially assume hardware & kernel as trusted and make sure that this trust then can not be violated from the outside (TPM, SecureBoot, VMs for each app, etc.). I just wish more people would focus on that promising approach.

<comment><USER9> > _able to compartmentalize something so critical and raw as a device driver._

QNX did this quite successfully; you could kill and reload e.g. a buggy network or disk driver. All that on top of being a realtime OS.

</comment></comment></comment></comment><comment><USER10> This was a fun write up.

On the off chance the author is reading the comments here, there are a couple security features they need to add for it to be more complete (I'm probably missing some things).

1) They should add a call to access_ok(VERIFY_WRITE, pointer, mem::size_of<Syscall>()) in rust_syscall_handle to ensures that the user space pointer points to valid userspace memory of the right shape for the syscall type.

2) They should sanitize (hopefully, using some zero-cost method) the Syscall type to guarantee that it is well-formed before calling handle. If the userspace constructs some normally impossible to construct Syscall, it's unclear how a rust match pattern handles it (i.e., if an enum has only 3 types and you pass in a falsely constructed variant with tag 100 is match guaranteed not to just be using a jump table and accidentally jump 100 instructions?)

<comment><USER11> Don't know about HN but a friend of the author posted this on reddit and was commenting there: [https://www.reddit.com/r/programming/comments/6f235k/rewrite...](https://www.reddit.com/r/programming/comments/6f235k/rewrite_the_linux_kernel_in_rust/dif9prj/)

edit: they also submitted it on HN, but it looks like they didn't get the "winning" submission: [https://news.ycombinator.com/submitted?id=fjallidergodur](https://news.ycombinator.com/submitted?id=fjallidergodur)

<comment><USER12> I am said friend, we're reading the discussion.

</comment></comment></comment><comment><USER13> Pretty cool. I decided to take a similar path in trying to improve/ensafen parts of the BEAM VM by finding small chunks I could rewrite in Rust from C.

Most of the headache was build toolchain integration stuff. I did manage to get a few simple things slotted in that appear to work transparently, which made me hopeful for future more complicated things to play with like new process mailbox implementations, etc.

Anyway, great write up and a cool project!

<comment><USER14> OT: I really like the word "ensafen", and I'm totally going to borrow it for future use

<comment><USER15> It's a perfectly cromulent word, and embiggens every sentence and phrase that includes it.

<comment><USER6> Embiggens? I think the point of the word is to debigulate some sentences. I _would_ say that it embetters phrases that include it; maybe that's what you meant.

<comment><USER15> Double plus good point.

</comment></comment></comment></comment></comment><comment><USER16> I'd rather see a rewrite of QNX in Rust, as open source. The QNX kernel isn't very large, but it offers most of POSIX, so you can run programs on it. (L4 is nice, but it does so little that people just use it as a hypervisor to run Linux. This doesn't simplify the problem.)

If you rewrite the Linux kernel in Rust, one module at a time, you'll just end up with C written in Rust syntax, with raw pointers all over the place.

<comment><USER8> QNX is also realtime.

In order to provide realtime guarantees that cover small latencies, you need infrastructure that generates as few instructions as possible. (If you have lots of instructions you can hit targets of a hundreds of microseconds since you can just wait. Start inching toward nanoseconds, though, and the scheduler's own execution will get in the way unless it's crazy compact.)

The reason I mention this is that QNX runs on a variety of embedded devices ([http://qnx.symmetry.com.au/](http://qnx.symmetry.com.au/) has an interesting list, universal remotes particularly jumped out at me) which are traditionally quite slow.

What's Rust like in terms of generating code that's _consistently_ compact?

<comment><USER17>
       What's Rust like in ...

Isn't that less a question of Rust (which due to its affine types, should be usable for generating code with predictable performance) but of compilers? It should be possible to write a Rust compiler that optimises for predictable performance at the cost of speed.

<comment><USER8> That's a fair point.

I don't quite follow why speed needs to be sacrificed to get predictable performance though.

And I don't know about _writing_ a (whole new?!) Rust compiler (!) - if the current Rust compiler wouldn't be a good fit for this purpose, well, I definitely don't have the resources to anything about that, considering the unbelievable amount of attention to detail and wrangling that's gone into getting rustc to where it is today.

<comment><USER17> Everything you say is true, but a _very_ simple compiler with little/no optimisations should be quite easy to write. Indeed it is often coursework in undergraduate compilers courses (for source languages simpler than Rust). The main difficult would be the type-checker, but you could reuse the existing one, for it does not affect run-time performance.

</comment></comment></comment></comment></comment><comment><USER18> It would cease to be Linux, but by all means -- make it so!

BTW Redox OS (written in rust) originally supported Linux syscalls which I thought was a super cool feature.

Jorge Aparicio started steed, a libc implemented in rust for rust. It seems like a pretty interesting approach.

<comment><USER12> Author said:

Thank you. Actually, I have a series of articles about a libc written in Rust for Rust which I started writing before steed was published, and… isn't finished yet. :-/ But maybe, I will finish and publish it eventually…

</comment></comment><comment><USER19> This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.

<comment><USER20> If there were a fork and the fork were to gain momentum it might be not be up to Linus.

A project like this might attract new developers because it might be less intimidating than joining the Linux kernel proper. There would also be the attraction of learning Rust in a very real world context.

edit:s/in/it

<comment><USER21> This is a good argument if a massive amount of effort was piled into this with lots of refactoring on top of it. Meanwhile, it doesn't have a snowball's chance in hell of accomplishing anything.

<comment><USER20> The key for such a project being successful would be to set expectations low in defining what success was. Something like "a proof of concept of an experiment to rewrite small amounts of the Linux kernel in Rust".

One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux.

Linus has stated that he isn't particularly interested in security bugs. Other people take a different view. Eg. [1], [2]

Another incremental step to improved security in Linux after a Rust fork might be to take the lessons learned to create a conservative set of Rust inspired extensions to C without all the hoariness of C++.

[1] [https://news.ycombinator.com/item?id=2539839](https://news.ycombinator.com/item?id=2539839)

[2] [https://www.schneier.com/blog/archives/2015/11/linus_torvald...](https://www.schneier.com/blog/archives/2015/11/linus_torvalds_.html)

edit 1: removed apparently dead link to original source [http://lkml.org/lkml/2008/7/15/296](http://lkml.org/lkml/2008/7/15/296)

edit 2: clarify that one wouldn't use the name Linux for the fork

<comment><USER21> "One would fork Linux on GitHub, name it something other than Linux, and just have the existing branches track Linux"

That's already hard given how many commits go into Linux. One must always remember it's not just some volunteer project: most of the commits are by paid programmers working at companies. That's where the labor comes from. You'd need a lot of volunteers to keep up with the paid programmers. Even Linux itself couldn't achieve that. Hence, all the paid programmers working on it.

"might be to take the lessons learned to create a conservative set of Rust inspired extensions to C without all the hoariness of C++."

Now you're thinking on the right track. That sort of thing has been done multiple times at the compiler level where they automagically make C safe with a performance hit. Several teams did it at CPU level. These projects have been used on FreeBSD mostly but also Linux. The strongest one so far is CheriBSD on CHERI processor.

Alternatively, for a safer C that you're manually using, what you describe has already been designed and actually inspired Rust's safety model:

[https://en.wikipedia.org/wiki/Cyclone_(programming_language)](https://en.wikipedia.org/wiki/Cyclone_\(programming_language\))

It could be revived and improved if people wanted. It got nowhere with C programmers, though, in the past.

<comment><USER20> So we agree about something at least ;-)

Slight tangent: I started my programming career in 1989.

The product was Parasolid and the language was AGA - a C inspired language that preceded C++.

I vaguely remember the following extensions:

* built in logging with Undo

* overloaded operators leading to vector and interval types that worked better than C++

* a proper module system

<comment><USER21> Interesting. Never heard of it. The main safe language from that time was Ada. It's been updated regularly. The neat thing about it is how it was systematically designed to mitigate errors in about every operation.

[http://www.adacore.com/knowledge/technical-papers/safe- and-s...](http://www.adacore.com/knowledge/technical-papers/safe-and-secure- software-an-invitation-to-ada-2012/)

There's also a variant called SPARK that can automatically prove the absence of errors like buffer overflow in a way that would normally take a theorem prover.

[https://en.wikipedia.org/wiki/SPARK_(programming_language)](https://en.wikipedia.org/wiki/SPARK_\(programming_language\))

<comment><USER20> >Interesting. Never heard of it.

You wouldn't of. It was developed internally to write Parasolid. Probably they still use it - several of the original devs are still there 30 years later.

<comment><USER21> IBM did that with PL/S. It was a system version of PL/I with no runtime and ability to decide how a function was compiled via annotations in that function. Kept getting updated but no public release. Here's a few more that you might find interesting for general usage that were proprietary or started internal:

[http://www.semdesigns.com/Products/Parlanse/index.html](http://www.semdesigns.com/Products/Parlanse/index.html)

[https://web.archive.org/web/20130303055647/http://www.founda...](https://web.archive.org/web/20130303055647/http://www.foundationdb.com:80/white- papers/flow/)

[https://en.wikipedia.org/wiki/Pike_(programming_language)](https://en.wikipedia.org/wiki/Pike_\(programming_language\))

[https://en.wikipedia.org/wiki/Roxen_(web_server)](https://en.wikipedia.org/wiki/Roxen_\(web_server\))

Parlanse is used in Semantic Designs' powerful toolkit. Flow was used to make a Spanner competitor, FoundationDB, that was good enough in some way for Apple to buy & pull off the market. Pike was used to build Roxen server that had significant advantages in its time period. A number of companies also used LISP and REBOL for their advantages with at least one asking LispWorks to do a real-time implementation for telecom or something. So, usually it pays to go with a common, often-crappy language with its ecosystem. However, doing one's own language with competitive edge does pay off at times. I think these days one can just do a DSL in Racket or Haskell on top of main language to negate benefits of _totally_ rolling own stuff. People got far with it, though. Galois is on a roll with that in high-assurance systems with this as an example:

[https://ivorylang.org/ivory-introduction.html](https://ivorylang.org/ivory- introduction.html)

So, just some fun examples of homebrew for you in return. :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> > (*pointer).handle();

Eek! That is, indeed, unsafe.

But this shouldn't be messing with the entry asm at all. Just add your new syscall to the syscall table, just like any other syscall.

</comment><comment><USER23> I wonder what makes AT&T assembly syntax "objectively crap".

<comment><USER24> You need to explicitly specify what the parameter sizes and types are. Plus, the parameters are backwards compared to Intel syntax:

      Intel: mov eax, 5
      AT&T: movl $5, %eax

In basically every C-like programming language, you assign 5 to eax with `eax=5` not `5=eax`. I can also tell that I'm working with the `long` variant of `mov` just by looking at the types involved.

Intel's syntax for memory access seems more natural. If I don't want to add `ebx` to the address, I can leave it out; I can't in AT&T; I have to have this seemingly random comma. Plus, what's with the format?

      Intel: mov eax, [ds:eax*4+16]
      AT&T: movl ds:16(,%eax,4)

<comment><USER25> Interestingly, in the language _you actually wrote that complaint in_ :

> you assign 5 to eax

AT&T speaks English, basically. We move A to B. Destination goes last.

Both seem sane enough. And in fact both get really balled up when you have three and four-argument instructions.

<comment><USER24> I'll grant that, but it's a programming language, so I kind of expect it to follow the order assignment does when I write in C++, C#, etc.

<comment><USER25> AT&T assembly style significantly predates C++ (and C# by like two decades), and co-evolved with C. And strictly this isn't an assignment, anyway. Assignment is an abstract operation in a programming language. This is a machine instruction[1] for a physical machine, which does exactly one thing.

[1] Pause while the peanut gallery points out that in fact there are like ninety six different instructions in x86 called some variant of "MOV". Yeah, yeah, we know.

<comment><USER8> _What._

When did `mov` get 96 different instructions?

<comment><USER26> I think it's just a bit of hyperbole. I don't know enough of this to know whether [http://c9x.me/x86/html/file_module_x86_id_176.html](http://c9x.me/x86/html/file_module_x86_id_176.html) is complete, but it gives you a sense of it all. (also [https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf](https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf) if you haven't seen it)

<comment><USER8> Huh, interesting.

Apparently there are 35 rows in the table at [http://www.felixcloutier.com/x86/MOV.html](http://www.felixcloutier.com/x86/MOV.html) (according to Chrome and `$0.childElementCount`). I only discovered gcc.godbolt.org links to documentation via context menu just the other day!

Regarding the PDF... _ouch_. Wonder if any executable obfuscators have tried that approach :P (and I also wonder what sort of overhead it has.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> I guess one of the things that always comes to mind when someone brings up "Rust all the things" is that it assumes that anything that can be expressed in C can be expressed in Rust _with the safety features enabled_. Rust wouldn't have a mechanism to do unsafe code otherwise, right? I think it might be more complicated than we might think initially.

I personally think that someone should probably spend some more time on GC that's performant enough for systems code. My convictions haven't driven me to do anything about it, however.

<comment><USER28> Safe rust clearly cannot express everything that can be expressed in C. It cannot even express everything that is safe in general. But "the safety features of Rust" includes drawing a barrier between the safe parts of your code and the unsafe parts. There is significant value in that compartmentalization. Moreover, you are assuming that things written unsafely in C should be written identically in rust, when there very well could be more idiomatic, modern ways to do the same thing without any unsafety at all.

<comment><USER27> There are modern ways to express something safely that is written unsafely in C. What Rust evangelists seem to forget is that there have been ways to do that for a long time.

The article actually has very little safe Rust in it. It makes me wonder what we are gaining? If the idea is that introducing Rust means that later you can go back and add type and memory safety...why not use C++ in a type and safe by construction way? Why not use Safe D?

I'm personally just looking forward to the hype dying down. I'm tired of hearing about it, and most of the time I just click "hide" on Rust articles because I'm not interested and people are starting to sound pretty shrill.

<comment><USER28> Have you ever written anything in Rust?

<comment><USER27> Like I said, I'm tired of hearing about it and, no, I haven't.

</comment></comment></comment></comment></comment><comment><USER29> >Rewrite Linux Kernel in Rust? Rust has no backward compatibility: C code compiles fine after decades. It would be a waste of time to rewrite Linux in Rust when the resulting code has a lifetime of few months until it won't compile and start breaking everywhere.

<comment><USER30> _> C code compiles fine after decades_

Early C code doesn't compile on modern systems at all.

Speaking of early C code, every vendor had their own version. C standardization had to go a long way.

Even today, writing portable C code is hard. Need a portable 128-bit integer? Good luck on Windows. Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms.

Oh, and int32_t was introduced in C99, which is not exactly "decades" ago, but admittedly that was 18 years ago. However, I wouldn't bet on portability of any code older than that, unless the authors of that C code were extremely careful and anticipatory. But then, with enough effort (and perhaps code generation), you can create portable code in any language.

Rust skips all that mess, by having a clear experimental phase in the 0.x versions. It became stable with a clear commitment to backwards compatibility since 1.0, which was released in 2015.

<comment><USER31> > Need a portable 32-bit integer? Better take a C implementation that provides > int32_t, because just using "int" bites you when switching from 32-bit to > 64-bit platforms.

Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of _pointers_ change.

<comment><USER30> Whoops. I meant 16-bit versus 32-bit integers, when switching from 16-bit to 32-bit systems. Sorry for the confusion. Fortunately, they didn't repeat that mess for 32/64 bits, at least not for integers, but "decades old code" is still affected.

<comment><USER31> Ah, yes. I agree, that was a mess!

</comment></comment></comment></comment></comment><comment><USER32> -> [https://mirage.io/](https://mirage.io/)

</comment><comment> throwaway-1209 Let's see what Linus thinks about this.

<comment><USER33> Probably the same as the author of curl. Something along the lines of "Yes, sure, our project is open source so fork it and go ahead".

<comment> throwaway-1209 "And don't call it Linux because I own the trademark".

</comment></comment></comment><comment><USER34> What is the rust communities obsession with suggesting (threatening?) rewrites of battle tested C programs that have been around for decades?

Now a kernel for a _new_ OS, that'd be something.

<comment><USER35> The article covers both of your points:

 _> Rust is supposed to be an excellent systems programming language, having the ability to go extremely close to the bare metal, while offering a thick layer of security and expressiveness which C lacks of. And such an assumption has to be trialled!_

 _> Which Philipp Oppermann has already done by beginning to write a real OS in Rust and writing about it. But this is not a realistic trial: an OS starting from scratch has almost zero chance to end up being finished, not to mention being actually used on real machines._

That is, a more accurate title might be "Proof of concept of incrementally rewriting the Linux kernel in Rust".</comment></comment>


Reactive Programming vs. Reactive Systems - <AUTHOR> https://www.lightbend.com/reactive-programming-versus-reactive-systems <comment><USER2> I don't understand why is this "reactive programming" even a thing. We, the IT industry, had exactly the same thing as systems' architecture and targets (as the "reactive manifesto" mixes the two together) for twenty years or more.</comment>


Ask YC : Future of IPhone Applications - <AUTHOR>

Hi Was just wondering , what do people expect of IPhone Apps ? Has Apple store reached a saturation point ?
email@example.com <comment><USER2> Touche... anyways expect more iphone apps, expect to be swarmed with them now that the nda is out the window, stop reading this and start developing something, its the cool new sandbox. No saturation point in sight. From a discovery and find point of view, saturation point for that long since pasted. But there is gold gravy on the iphone, and all future mobile platforms that follow.

</comment><comment><USER3> People asked the same things about the Facebook platform 3 months out.

Here's the reality: The apps that made the most money in the long run did not launch in the beginning of the platform. Those who launched in the beginning did not gain any leverage by which their other apps grew. The biggest apps on Facebook are not those who launched early on (with a few VC backed exceptions).

My point: the best is yet to come.

</comment><comment><USER4> Punctuate correctly. Remove your email address.</comment>


Petition on Digg to remove power users has 19000+ Diggs - <AUTHOR> http://digg.com/tech_news/Digg_this_if_your_sick_of_power_users_stealing_stories?FC=PRCT1 <comment><USER2> Can somebody explain the outrage? Is there any incentive to being a power user on digg (beyond getting your name on the front page?). Is there any monetary incentive? SEO opportunities perhaps?

</comment><comment><USER3> But did a power user submit it?</comment>