Correct or inotify: pick one - <AUTHOR> http://wingolog.org/archives/2018/05/21/correct-or-inotify-pick-one <comment><USER2> When implementing inotify for SmartOS to implement LX-branded zones, I could not help editorializing on some of its design defects -- most of which spilled into the man page.[1]

In the end, I came to the same conclusion as the author: while inotify is much better than dnotify (and relatively better than misconceived interfaces like epoll(2)), its flaws remain serious and it would be frustrating to write a correct application based upon it.

[1] [https://smartos.org/man/5/inotify](https://smartos.org/man/5/inotify)

</comment><comment><USER3> The BSD kqueue has similar problems, in a different event domain. The semantics of the interface and the mechanics of the data structures mean that an EVFILT_PROC event with NOTE_FORK will be overwritten by an EVFILT_PROC event with NOTE_EXIT for the same process, meaning that it is not possible to always correctly track the children of processes that fork and then rapidly exit, or of ones that rapidly fork multiple times.

Fixing this would entail letting go of one of the architectural concepts of the system, either that a filter+ident pair uniquely identifies an event in a queue or that a process only ever has one event queue. (Letting go of the latter also entails a further mechanism for polling multiple event queues.)

<comment><USER4> I think the issue, ultimately, is buffering. Kernel interfaces that can't preallocate space at request time are problematic. If you can allocate space sufficient to store the event(s) at the same time that you request notification, error handling is easy and obvious from a design perspective. Unbounded, asynchronous buffering in kernel space is simply a non-starter unless you don't care about consistency and reliability. Linux developers generally follow (coincidentally?) the GNU directive[1] of lazy, dynamic allocation, and it's why Linux interfaces can be so problematic and why everybody throws up their hands when one raises concerns about OOM handling.

The reason EVFILT_VNODE works where inotify doesn't is precisely because EVFILT_VNODE requires an open file descriptor, which indirectly behaves as a preallocated buffer for storing pending events. But just like with signals, like events are coalesced and ordering can be lost.

I think the most straight-forward solution to fork notifications is to _block_ the forking process if the event can't be enqueued. That might be the only proper solution, period, if you want guaranteed delivery _with_ the new PID. That creates the potential for deadlocking, but that already exists with other facilities like file locking, pipes, etc.

[1] [https://www.gnu.org/prep/standards/standards.html#index- arbi...](https://www.gnu.org/prep/standards/standards.html#index-arbitrary- limits-on-data)

</comment></comment><comment><USER5> John Siracusa has a good description of OSX's equivalent. [https://arstechnica.com/gadgets/2007/10/mac- os-x-10-5/7/](https://arstechnica.com/gadgets/2007/10/mac-os-x-10-5/7/)

I assume it hasn't changed too much in the past decade?

<comment><USER6> tl;dr

> The FSEvents framework relies on a single, constantly running daemon process > called fseventsd that reads from /dev/fsevents and writes the events to log > files on disk (stored in a .fseventsd directory at the root of the volume > the events are for). That's it.

> "The FSEvents framework, in turn, can only tell its clients, "Something has > changed in directory /foo/bar/baz."

> Clients of FSEvents are expected to then scan the directory that has changed > in order to determine what, exactly, happened (assuming they're interested > in that level of detail)."

<comment><USER7> FSEvents is largely just a support infrastructure for Time Machine. Time Machine doesn't need to know about every single change, it just wants to be able to avoid having to scan the entire disk every time it goes to make a backup. This can be generalized to other backup utilities as well, or really any utility that periodically needs to check the state of the disk against some snapshot of that state. Under these conditions, "something changed in directory /foo/bar/baz" is sufficient because the directory itself can then be scanned.

<comment><USER8> Just because you don't know other examples doesn't mean it only exists for Time Machine. Many other things are interested in changes to the file system, for instance programs that sync a folder to a cloud service, Finder which wants to show a live view of a folder or alternative backup applications.

If there was no use for this outside of Apples own apps they wouldn't have given it a public api.

<comment><USER7> Many things that are interested in the filesystem would use kqueue instead of FSEvents, as kqueue can give fine-grained event notices as opposed to FSEvents's course-grained "something changed in this folder".</comment></comment></comment></comment></comment>


Remote Execution Flaws a Risk to Spring Framework Applications - <AUTHOR> http://www.securityweek.com/remote-execution-flaws-risk-spring-framework-applications

<comment><USER2> There is no information in that article except generic language about injection.

I believe this is the actual advisory: [http://www.mindedsecurity.com/fileshare/ExpressionLanguageIn...](http://www.mindedsecurity.com/fileshare/ExpressionLanguageInjection.pdf)

It appears that spring double evaluates the expressions, so you can send a request param that is an EL expression that references values present in the server environment.</comment>


Evidence of massive-scale emotional contagion through social networks (2014) [pdf] - <AUTHOR> https://www.pnas.org/content/pnas/111/24/8788.full.pdf <comment><AUTHOR> Past coverage (though using the abstract at the time):

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

I think this is one of the more important papers in the past ten years, and it seems like a shame how few people have read it.</comment>


Iphone hack: Type *3001#12345#* and then hit call - <AUTHOR>

This brings up the Field Test app, where you can change the standard reception bars to decibels referenced to one milliwatt (dBm) for greaer accuracy when looking for a signal.
https://www.quora.com/What-cool-things-can-one-do-with-an-iPhone-and-iPad-that-most-people-dont-know-about
FanFootage.com <comment><USER2> This is helpful - [https://www.quora.com/What-cool-things-can-one-do-with-an- iP...](https://www.quora.com/What-cool-things-can-one-do-with-an-iPhone-and- iPad-that-most-people-dont-know-about)</comment>


Go Is a Shop-built Jig (2014) - <AUTHOR> http://robnapier.net/go-is-a-shop-built-jig <comment><USER2> I've always felt this is one of the better characterizations of Go. Great programming tool. Not an especially great programming language. A lot of the time, more than we acknowledge in PL slapfights, that's what you really want. And, sometimes, being in an efficient but limited language allows you to focus better on your problem domain, which can be useful creatively.

<comment><USER3> On Go-the-language, I agree. It takes a few things from PL design that have widely been shown to be helpful and packages them up in a simple language that C/Java programmers can use to be productive in an hour or so.

The implementation is a different story. It was really goofy to implement a new compiler backend, garbage collector, scheduler, calling conventions, and hey, why not make have the standard library make syscalls directly, what could possibly go wrong? The result has been the last several years has largely been spent reimplementing solved problems (basic compiler optimizations, a GC which is competitive with JVMs from 15 years ago, etc) rather than actually evolving the language.

In short, I wish they'd stuck with their "just do a few things well" philosophy in both language design _and_ implementation.

<comment><USER4> The compiler backend, till the Go rewrite, had been in production use for ~15 years or so from the top of my head, it's just neither GCC, nor the new hotness LLVM.

Calling convention TBQH is something that often has to be custom in a language outside of interop bits, otherwise you are forced to deal with various C-style brammage. Unfortunately most OSes don't have language-independent interop calling conventions (Windows has COM, VMS has, iirc, SDL, the rest pretty much has nothing), so even if technically there's some official document practically you get stuck with peculiarities of a specific compiler and its relationship with C standard library. Syscalls are about the only _safe_ interface on most unices and the reason why you can make self-standing Go programs that don't bring glibc garbage and random and unexpected shared library dependencies, something that is quite a reason for the following Go gets on container based platforms.

</comment></comment></comment><comment><USER5> I cannot really put my finger on it, but Go is basically perfectly compatible with the way my brain works. Its semantics so far have not surprised me, and I only have to look up the language specification very, very rarely. Most of the time (like 90+ %), I can just let my intuition guide me. Of course, Go has its share of problems, but that one huge advantage dwarfs those problems entirely.

<comment><USER6> That, plus the lack of magic.

I can always understand what a Go program is doing because of the simple semantics and lack of magic. It's an underrated benefit to be able to browse the source code of a dependency and grok it easily, first time.

</comment></comment><comment><USER7> > _I would rather spend my time writing generic, elegant functions that help > developers_ think deeply and correctly _about their programs. Like Alex, > falling back on for-loops and mutable state makes me feel like a bad > programmer. But there is a certain tension between all that and_ shipping > things today.

(Emph. mine)

It hits the nail on the head: there's a certain tension between speed and correctness. For some, there's never enough time to do the right thing, but always (inevitably) enough time to keep fixing a wrong thing.

There are also diminishing returns of typing imperative code fast top to bottom, but having to deal with constant boilerplate and manually checking things that a machine could check, were the language more expressive.

Somebody called Go "systems PHP"; I think it's very fitting.

<comment><USER8> Ehhh I dunno about the PHP thing. I can see what you mean, but there's a certain negative implication to it which isn't accurate. PHP is bad because it's inconsistent and doesn't really have a coherent design. You can tell that it evolves by having things bolted on to it, and there's all sorts of weird dark corners. Go really isn't like that at all.

<comment><USER9> I disagree that PHP does not have a consistent design. Since PHP 7 they have been intentionally removing all old PHP warts and pushing the language to real consistency. They even have an RFC process now for proposing new features from the community so they can be more responsive.

It's not statically typed like Go but it's far from inconsistent IMO

<comment><USER10> I do PHP a lot and it is extremely inconsistent. Even PHP7. Like half of standard library uses _ and other half does without them (var_dump(), phpinfo(), gettype(), get_class()). Half uses to other half 2 (deg2rad(), strtotime()). So many bugs because of comparsion and operators doing wierd stuff.

PHP is mad. I think they have to keep it for legacy reasons.

Don't get me wrong i think the way php handles requests is useful for the small websites i create and i would probably not use any other language for that. But PHP is THE dirtiest most inconsistent language that people actually use.

<comment><USER9> Perhaps I have a little bit of a knee jerk reaction. I've gotten a new job where I have to do php development pretty heavy, and I haven't done it since I was 19 when I was interning at my first programming job and I absolutely hated it. Back then php 5.5 I think was the latest version and it just felt incredibly impossible to get anywhere with it. It wasn't long after that I moved to Python. I only recently got a different job all these years later where I am doing it again but PHP 7 is just so much better. 7.2 in particular even though its a point release has even done a lot to improve it.

So I feel like there is this level of people who look at people who have to do PHP and actually enjoy it (and I have to say I am enjoying it, warts and all. Drupal is OK but where it really shines is [https://laravel.com](https://laravel.com) ) like we aren't 'real' programmers unless we somehow know its a terrible language and are only doing it because we have to.

I really like it.

With that said, if I'm being completely honest here, there are parts of the PHP community that just down right drive me nuts. There are a lot of scammy companies out there trying to sell PHP solutions that are such garbage. Its like JavaScript. PHP does have a low barrier to entry (but a high bar to being good at wielding it, much like JS. You could probably make this argument for a lot of web tech in general) that all kinds of people use it and really feels like it sullies the language quite a bit and some of the community around it.

Alas however, much like everyone hating jQuery without ever actually explaining themselves or what is the technical aspects of jQuery that make it so undesirable, PHP occupies the same space: everyone loves to hate it, it seems.

</comment></comment></comment></comment></comment><comment><USER11> I've written production code in Go professionally every day for two years. None of the language design complaints in these thinkpieces are a real problem. You learn the idioms and it works out.

Go's showstopper problem is dependency management. Fighting with Glide costs at least 30% of my time and every moment of it is excruciating. My organization started migrating to Dep just as Google announced its decision to have the Go community continue thrashing around on the issue even longer.

My advice: do not even begin to engage with the details of the langauge. That's a waste of time. Understand that dependency management is horrifically broken and that Google considers it reasonable to thrash between experimental half-baked solutions forever. However much you may hate Java, Maven terminates with a correct output in less than an hour, which is more than I can say for anything in the Go ecosystem.

</comment><comment><USER12> The error handling in Go seems verbose:

        if err = logit(FrobulatingMessage); err != nil {
          return err
        }

        if err = f.cleanupOldest(); err != nil {
          return err
        }

There's an advantage, though. You can easily insert code for an error case. You might add, if cleanupOldest fails, something like

        logError("cleanupOldest failed unexpectedly while cleaning up chain")

if that's an unlikely but possible event that needs to be investigated. Big operational shops do that. It's hard to stick debug code in the middle of an expression.

<comment><USER13> The equivalent in rust, for a fair comparison:

Before:

        frobulate(message)?;

After:

        frobulate(message).map_err(|e| {
          error!("error happened: {}", e);
          e
        })?;
        // or, more like the go one
        if let Err(e) = frobulate(message) {
           error!("error: {}", e);
           return Err(e);
        }

It's really not that different in the debug case than go, but the normal case is less painful to deal with.

</comment></comment><comment><USER14> I love Go, I really do. But there are some issues that should be fixed (maybe in 2.0).

I'm not so sure if we really need full-scale generics like in Java or Rust, but the interface system (which is the Go solution for the Generics use-cases) certainly needs some improvements. For example, when you write a container lib which expects an empty interface as input you constantly have to cast the type while using the lib. The result is code which looks awful when you use the container and horrible when you look at the container implementation.

Next, using slices of interfaces is just another bad joke [1]. there might be technical reasons for the current state, but I am sure there are ways to solve those issues.

One thing I am not quite sure about the way Go handles bindings methods to interfaces. Currently, that is not supported and the practical way to do it anyway is to embed the interface into a struct and bind the methods to that struct, but that feels more like a hack than anything else.

Another thing that keeps bugging me is the requirement for map keys to be comparable while that is just some internal property which some types have and others don't. For example, functions are not comparable and therefore you can't use them as map keys. Finding out about such stuff really sucks when functions are considered first-class citizens.

That said, I have to add that I enjoy a lot of the positive sides of Go and while I wish those issue will be fixed someday, I will gladly continue to use it even with those issues.

[1]: [https://github.com/golang/go/wiki/InterfaceSlice](https://github.com/golang/go/wiki/InterfaceSlice)

<comment><USER15> I don't understand: what do you mean with binding methods to interfaces?

Interfaces just represent a bunch of functions that an object must provide (and you can call when you "mask" the object behind the interface).

<comment><USER14> Well, normally you bind functions to types like:

      func (m myType) calcRandom() int {
        return m.nine
      }

But there are some situations when it would be useful to be able also bind functions to interfaces (e.g. some of them are similar to use-cases for abstract classes in OOP):

      func (i myInterface) calcRandom() int {
        return i.Nine()
      }

While I would consider it a clean language design to be able to do that too, it brings some additional complexity and as we know Golang doesn't like complexity.

As I said, I am not completely sure of the consequences such a change would bring with it and if it would enable bad practices. So I would not push too hard for that one, but some of the other issues I mentioned are issues of which I am pretty sure that they should be fixed.

<comment><USER6> um.. I think you've confused the interface and the implementation.

Interfaces are not the same thing as classes, and bringing anything from OOP to them will almost certainly result in Bad Things.

</comment></comment></comment></comment><comment><USER16> This article contains a dead link in the third paragraph marked as "bugs the lead language designer". Here is an archive.org link from the same time period: [https://web.archive.org/web/20140822173033/http://gophercon....](https://web.archive.org/web/20140822173033/http://gophercon.sourcegraph.com/post/83845316771/panel- discussion-with-go-team-members)

</comment><comment><USER17> > When writing the Swift function, I found myself spending a lot of time > thinking about how to write it. Should I use >>== or .flatMap()? Should I > use my custom Result here at all, or should I stick to standard Swift and > return NSError?, or maybe Bool with an NSErrorPtr? This was my first time > using Result<Void>, and I started asking myself if I should create a > typealias for that and maybe a helper function for the slightly strange > looking success(()). The var bothered me. It always feels like a hack in FP, > like you're not smart enough to do it right. I wrote a different version > that didn't have a var. That duplicated self.cleanup in two places. So I > started working on a new function that would let me include the conditional > in the functional composition. I made and re-made a lot of choices.

This has basically been the entirety of my experience with Scala. Having too many options - including just writing Java without semicolons - is ultimately not great for my own productivity.

</comment><comment><USER18> _So again, in the end, Go turned out to be a language for solving real problems rather than a language filled with beautiful tools, and so you build real solutions rather than finding excuses to use your beautiful tools. Don't try to make Go what it isn't. If you're trying to solve abstract CS problems in their most generalized forms, then you may find it frustrating. But if you're trying to solve specific, practical problems in the forms professional developers typically encounter, Go is quite nice._

This is a straw man argument. How many people who complain about Go -- or evaluate it for a project, drop it and move on -- start out solving non-real problems?

</comment><comment><USER19> Though to continue with the analogy, you don't want your entire workshop to consist of ad-hoc tools that kinda-sorta work for narrow purposes. You want your basics to be solid, well-designed, and applicable generally - so that you're not already having to account for their individual exceptions and shortcomings when you layer your hacky jigs on top.

I feel like there's a physical workshop analog of how (Lisp) macros get you _one and only one_ additional layer of abstraction. I've made an impromptu "table saw" by fastening an upside-down circular saw to a piece of plywood, but it certainly wasn't a basis for doing anything greater and I had to be real deliberate about plugging that thing in.

</comment><comment><USER20> This is exactly what I feel when using Go. Love the way I can really focus on solving real problem rather than trivial (but important things like styling and formatting). About generic, when I thought need it, I always able to find simpler design using composition.

<comment><USER21> > _About generic, when I thought need it, I always able to find simpler design > using composition._

How exactly would composition help you e.g. make a general purpose reusable math library for different kinds of numeric types?

<comment><USER22> I think the implicit argument is that "a general purpose reusable math library for different kinds of numeric types" _is not_ a real problem.

A real problem is, "I need to draw this triangle", and using math.Cos w/ float64s works just fine.

<comment><USER21> And yet it's a problem anybody who makes any kind of library that should work with > 1 types, faces...

Not just math and scientific libraries. Even a simple reusable data structure. And fact it's so commonly needed for this, that Go's slices and maps would have been useless unless Go's designers have not cheated and used genericity for themselves...

And let's not get into reusable abstractions for behavior -- like a library that encapsulates the 5-10 more common uses for channels and goroutines (span N goroutines and wait for all to collect the results, span N and use first result, and so on).

</comment></comment></comment></comment><comment><USER23> In Swift, what's wrong with writing the imperative version to start with, then switching to the monadic version as there's time to polish, or as the function logic evolves to a point where other styles are clearly preferable?

<comment><USER2> Nothing at all. His point is just that there's cognitive burden associated with making those kinds of decisions in Swift, and there isn't in Go, because you don't have those options. All things considered, he prefers Swift. But he's productive in Go as well.

I've had similar experiences. I find that for some problems --- not all of them --- I can drill in quicker in Go, because the problem is all I can really think about; there isn't enough elbow room in the language to really spread out and work on the task of making things elegant.

At my last company, I found that writing an emulator in Go was super straightforward, and I think Go made that task easier than a "better" language like Clojure or Swift would have. But in addition to an emulator, we also wrote a compiler, and writing a compiler and SSA optimizer in Go was fairly unpleasant. Not prohibitively so, but enough that I noticed it.

<comment><USER24> I think it's kind of akin to the premature optimization people do when they think they have 'big data', but really don't.

If you're really doing heavy list processing, transforming complex data structures, etc., then you're probably going to miss map, reduce, and friends. But for most real world problems, the code is faster to write, faster to run, and easier to understand with a few dumb loops.

It's always tempting to do things the clever way, but Go made me realize how rarely it's actually beneficial.

<comment><USER25> For compilers and optimizers, people have said pattern matching support in the language is very beneficial. I bet there are other tasks where something like algebraic data types and pattern matching would make the code much simpler, and it's not really hard for the language to implement.

</comment></comment></comment></comment><comment><USER26> The title of this submission reads like a No True Scotsman fallacy.

</comment><comment><USER27> I think this is from 2014?

Anyway, it hardly seems fair to give yourself choices (by introducing that "LlamaKit" library) and then criticizing Swift because there's different ways to approach the problem.

(And I wonder if LlamaKit does anything besides obfuscate code? Hopefully I'm just missing some context.)

<comment><USER2> He's not criticizing Swift. He's a Swift programmer who prefers working in Swift to working in Go.

</comment></comment><comment><USER28> it impossible to not roll my eyes when i read such a title.

</comment><comment><USER29> Flagged for changing the blog post subject to clickbait.

</comment><comment><USER30> > Very cross-platform out of the box. Not "sort-of cross-platform as long as > it's unix" like C/C++

Wut? Firstly, no it's not. I have to drop into MinGW just to interface with native libs statically. Many languages don't do this. Secondly, C++ is very at home on Windows. Not a very good FFI story for something that is very cross- platform that it only binds w/ C libs with only one Unix compiler (gcc). It's like you got the phrasing exactly backwards and need to switch Go and C/C++.

> Go feels under-engineered because it only solves real problems.

Until I list the ones it doesn't. Or are they not "real"?

You know what? I'm not reading these things anymore. We know the type...supposedly senior devs writing a bunch of words about one language over another, cherry picking specific things for both to fit the narrative. I feel like this is how Michael Moore would write blog posts comparing languages. Sorry to hop on this article like this, saw it a couple of days ago with the Java/Kotlin blog post too and I'm seeing it every so often. And I like Go and Java. I'm afraid I just don't see these language opinions as that valuable anymore since I write in them all myself and know better.

Edit: In retrospect, probably a bit harsh. But I'd prefer the journalistic lang X does this but not this approach over the op-ed.

<comment><USER2> I'm an old C++ programmer who's had the pleasure of doing an XP codebase and I would pick Go any day of the week over the early-aughts C++ I remember working in --- but I concede this may have gotten better since then.

While I don't think he was trying to say Go solves _every_ real problem (rather, just that the subset of problems Go solves are all practical and not theoretical), it would be constructive if you could take the time to list the problems you think Go is bad at solving, and why.

I'll probably agree, but I may also learn something, and I'll _definitely_ learn more about where you're coming from.

<comment><USER30> While I would choose Go too, my specific complaint was about saying that Go is very cross platform and C/C++ are only sort of in a Unix way. Not only do I think Go has cross-platform issues wrt Cgo and that they only support gcc (but hopefully changing [0]), but that it is incorrect to say C/C++ is "sort-of cross-platform as long as it's unix". Those types of statements turn me off the article. So I stopped reading after that and the "real problems" statement.

I'm not sure it has much value to list places where Go may not solve the problem because we all know the limitations of our languages/platforms/runtimes. Among places Go is not the best: low-level embedded software, very performance critical software, software static correctness is more important than maintainability, etc. It's like saying Rust solves all real problems. While I guess mostly true, it doesn't mean too much to me. In general, I'm just finding these posts have little value to me anymore.

0 - [https://github.com/golang/go/issues/20982](https://github.com/golang/go/issues/20982)

<comment><USER31> This is just disagreeing on definitions. You're assuming a particular definition of "cross-platform" and I think what they mean is that pure Go (using its standard library) is very portable. It's great if the standard library does what you need.

<comment><USER32> A portable stdlib does not a portable language make.

</comment></comment></comment></comment></comment><comment><AUTHOR> Edit: I had used a quote from the blog post as the title, but updated it to match the blog post as I realised it was a mistake.

The original title was: "Go feels under-engineered because it only solves real problems".

</comment><comment><USER33> Go might be nice and all, but I could probably never in good conscience use it seriously, for one simple reason: It's dominated by Google. It was started by Google, and all of its core development (I assume) is done by Google people, with Google's blessing. It's even _named_ for the company, making the ownership transparent and obvious to all.

With something like C, C++, Lisp, Python or the like, you _know_ that even if some large company abandons it, it probably won't even make the headlines, since it won't matter much for the rest of the users of the language – it has a large enough user base that the language will be fine.

But what if the controlling company decided to abandon Dart, Swift, C#, Go, etc.? It would kill the language in an instant. Or if they decided to simply take the language in a new direction more suited to the company but contrary to the wishes of its global user base? I can't work under those conditions, and neither should anyone else accept to do so.

To clarify: _If_ , say, _at least_ two thirds majority of the development of the language was no longer done by a controlling company (and if the supposedly non-affiliated developers were not also all incidentally employed by the same company), and, in the case of Go, the name was changed, I would probably not have a problem with using any of the aforementioned languages.

P.S.

Rust is a slightly special case, since it's dominated not by a company, but by the Mozilla _Foundation_ , making it slightly more dependable than an arbitrary company.

<comment><USER21> > _Go might be nice and all, but I could probably never in good conscience use > it seriously, for one simple reason: It's dominated by Google. It was > started by Google, and all of its core development (I assume) is done by > Google people, with Google's blessing._

I don't think Google is particularly the problem here. Go has lots of people working on and with it from outside Google.

The problem is that the core team is very resistant to any kind of outside ideas (while not being always brilliant with their ideas to compensate) -- and the community has fossilised to those loving the same ideas as well. It encourages a groupthink that's not there in other languages.

Contrast with e.g. Swift, which while run by Apple, has a great community participation story (to the point to going into too much bikeshedding).

<comment><USER4> A significant part of it is that there's a disconnect between a bunch of the core team, and the rest of the world, because even said fossilized group of the community often has no idea about certain Go fundamentals (like that significant portion of the runtime is copy-paste rewrite of certain C libraries, libs that even were part of the runtime before the rewrite, and that Go is verily not unix/posix native language).</comment></comment></comment>


Google reinstates federated Jabber/XMPP instant messaging - <AUTHOR> http://www.fsf.org/blogs/sysadmin/google-reinstates-federated-instant-messaging

<comment><USER2> This incident discredits the FSF's legitimate and usually very good flagging of internet misdeeds.

The FSF started out by saying Google was blocking some federation between domains [and the sky is falling down]. The implication being that because they are big there must be some malicious intent. Google had mentioned the problem on the XMPP operators lists and, their messaging team are a pleasure to work with (we send a lot of buddycloud messages to Gtalk users over their XMPP network). This FSF post created a shitstorm for no reason.

Of course we should aim for full federation. But let's look at Google's position: When (I'm guessing here) 1% of your XMPP traffic is federated, it's in Google's interest to look after their existing users and protect them from a bunch of spam than to federate with smaller domains. It's a no brainier - not an evil plan.

PS: It's called XMPP. Jabber is a trademark owned by Cisco.

<comment><USER3> From the original article that you mischaracterise:

"According to a public mailing list thread, Google is doing this on purpose, to handle a spam problem. We sympathize; we spend a disappointing amount of energy combating similar problems on the services we provide for the free software community. But the solution can't be something that breaks legitimate communication channels, and especially not in a way that enhances Google's disproportionate control of the network."

</comment></comment><comment><USER4> I remember when Google used to have an in-browser GChat app connected directly to XMPP through JavaScript or another frontend language. I still have my hopes that they will release an open source framework to embed a similar IM chat into a website layout.

For reference here's a screenshot I found in Google Images: [http://developers.sugarcrm.com/wordpress/wp- content/uploads/...](http://developers.sugarcrm.com/wordpress/wp- content/uploads/2009/01/google-talk.png)

<comment><USER5> I'm working on a Javascript XMPP webchat client built with Strophe.js and backbone.js

Please check it out <http://conversejs.org>

You can connect directly to any public XMPP server and you can of course set up one yourself if you want to maintain ownership of the data.

It's still early days but it's already quite useful and used in production (integrated into an add-on for the Plone CMS).

<comment><USER6> You should setup a test XMPP server, so we can try the client without having to actually sign-up for an account.

<comment><USER5> Yeah, I'll definitely do that sometime!

Currently I just want to get the client as polished as possible.

Once that's done and the XMPP server is up, I'll make a post to ShowHN.

</comment></comment></comment></comment><comment><USER7> I have to admit, I didn't expect them to fix this.

<comment> mh- not that they have any obligation to do so, but: in the absence of some commitment to this remaining available, I'd be hesitant to build reliance on it.

<comment><USER8> This is how you should treat most things on the internet.

<comment><USER9> Or in meatspace.

</comment></comment></comment></comment><comment><USER10> This is a really bad title, since they were only ever blocking invites, not messages.</comment>


Show HN: New Performance and Quality Test Reports on DareBoost - <AUTHOR> https://www.dareboost.com/en/report/555bb96be4b0f9b44d9a2e5d

<comment><AUTHOR> After a first post on HN we had great feedback (thank you guys!), and we just released this new version to go further!</comment>


The Tata AirPod: a car that runs on compressed air w/150-200km range - <AUTHOR> http://stoweboyd.com/post/29621528557/the-tata-airpod-is-a-city-car-running-on

<comment><USER3> The company behind this invention has been talking about the roll out of these cars for many, many years (<http://en.wikipedia.org/wiki/Motor_Development_International>). And this particular blog post doesn't give any details of when Tata is going to actually produce a car. I recall a long time ago that these cars were going to be introduced in Mexico (that was one of many things that didn't happen).

Wikipedia has good articles on compressed-air engines and cars. Here: <http://en.wikipedia.org/wiki/Air_engine#Automotive> and <http://en.wikipedia.org/wiki/Compressed-air_vehicle>

Tata has been a licensee of the technology since 2007 (<http://www.gizmag.com/tata-motors-air-car-mdi/22447/>). When they go into production it will be interesting news.

<comment><USER4> This.

So back in 2007 I saw that Tata had licensed the technology for using the air- motor in its cars. As an infrastructure guy I thought "Hmmm, if this stuff works, I could use it in a data center." So I tried to do that.

Here was the plan, using a windmill you could compress air, it's a pretty simple mechanical linkage, run a pump off the rotating vanes, has been done for hundreds if not thousands of years. But instead of water, you pump air into tanks. This generates heat because you are compressing the air of course but its windy so you've got heat sink vanes in the air flow being cooled by convection. Now at some point your data center wants a bit more juice, so you dump air through these MDI engines, which are running electrical generators. But here is the thing, when you dump the air it gets colder, a lot colder and the pipes can freeze up, but this is a _datacenter_ and you run the pipes through the data center and cool _it_ epic win! Power and cooling for free, the more power you use the more cooling you get, how neat is that?!

Except there was no amount of money I could give MDI in exchange for engines. They don't make the engines, they don't have a plan to make the engines, they won't let someone build the engines and sell them at a profit because they won't license them to do so. I was a classic case of an inventor being so unrealistic about what the value of their invention is, they prohibit the creation of a market around it.

The trick is that markets have choices, and an air engine would be a good choice, but not if it is not cost competitive with high efficiency diesel, or cheap (and dirty) two stroke gas engines. After I gave up (by mid 2008) trying to get them to see the error of their ways I figured it would be 20 years until we saw a credible use of this technology because all the patents would finally expire, and people would start to make them, and probably curse the folks at MDI for their short sightedness.

<comment><USER5> > Power and cooling for free

It's not in the slightest free. If you attached your windmill to a regular electrical generator, then used the electrical power as needed, plus a standard A/C you would come out ahead vs first compressing air, which is very wasteful.

The reason it's so wasteful is the "you've got heat sink vanes in the air flow being cooled by convection". You are throwing away energy there.

<comment><USER4> You are pedantically correct sir, but there is a larger context. So in that larger context I was working on this plan when working for a company that had a data center near the Columbia River and 'industry leading' PUE numbers.

Generally when the wind was blowing (and it blows a lot along the Columbia River Gorge) there is no need for additional cooling. When there is no air movement and the outside temperature is high, the demand for cooling increases requiring a more 'active' engagement (sorry but I can't be more specific than that).

So realistically I was looking to time shift the excess cooling capacity that was available during windy times to the times when there was little wind and excess heat. Compressing air has some advantages in that the amount of energy you can get out vs the amount you put in is comparatively efficient to battery power, and using / exploiting the cooling effect of the expanding air, and the kinetic energy of its expansion to generate electricity, was actually more efficient than other methods. Maintenance burdens were also lower and municipal permitting was made easier by the lack of 'dangerous' chemicals or catalysts.

These advantages are perhaps uniquely suited to data centers. Of course I didn't get to actually build it because MDI wouldn't participate. That was too bad but certainly well within their rights.

<comment><USER5> Essentially what you are saying is that your want to (also) store cold rather than store just energy.

I'm not convinced it was worth it. You anyway are collecting energy from the wind, and instead of storing it as energy you stored (part of) it as (potential) cold.

But in order to do that you threw some of the energy away - I suspect that if you stored all the energy directly, and then created the cold on the spot as needed you would have higher efficiency.

If I did want to store cold I would not do it using compressed air, I would use a water tank - cool the water to ambient (no active cooling, just some pumping) then dump heat into the water when necessary.

<comment><USER4> Perhaps when I get a chance to build my own data center for Blekko I'll be able to actually run the experiment [1]. Then I'll have a better answer. But would like to share a bit my reasoning.

You are correct that my concept 'threw away' the heat generated by compressing the air. However, since any energy stored at all was collected from a previously unharnessed source (the wind blowing past the data center) it might be more accurate to say that it would not collect all that it 'could'. But here is a very important distinction, the heat from air compression is 'low grade' heat, which is to say the delta between it and ambient is small enough that harvesting it in meaningful amounts is quite difficult. You also need to consider that this thing is operating next to a data center which is running an evaporative cooler 24/7 to pull excess heat from inside the box and dump it into the air outside the box. Basically spending energy to move the heat outside.

So from this side of the screen, to accept you point that not capturing the heat generated from compression was 'throwing it away' I would need to have some credible way of utilizing the captured heat.

Looking at it from the overall energy exchange picture, you've got the kinetic energy of the wind, with is 1/2mv^2 where m is the mass of the wind moving pass the windmill. Some percentage of that you convert to mechanical energy which runs the air pumps and some of that becomes heat in the bearings and linkages. The mechanical energy then compresses the air which by the ideal gas law goes up in temperature proportional to the change in volume. Just sitting there, the tanks holding the air cool off, losing this heat to the surrounding atmosphere. We could insulate the tanks to keep it inside (and pressures up) but it turns out that we'd like to harvest heat energy out of the data center later so we let this heat leave by convection. The tanks then go down in pressure thanks to that same ideal gas law.

So when we use this air, we decompress it inside our data center. This allows heat in the data center to be absorbed by the expanding air, which saves us the energy we would have been using to run the evaporative coolers to pull it out and increases this energy available in the air as it increases that static pressure differential between ambient and the decompressed air. So we 'get it back' as it were, in a positive way. Running it through the engines allows us to then harness the pressure differential, and if it comes out of the engines still 'colder' than the data center air we can inject it right into the regular atmosphere of the data center to offset warm air that is already there.

[1] Facebook also has a data center up there in the region and if someone there wants to pick up the ball and run with it that would be pretty cool to. You could write it up for the open compute stuff. Of course you still have to figure out how to get an MDI engine. If Tata ever shipped I considered buying cars, throwing away the body and just pulling out the engines. That would work but requires Tata to actually have a product you can buy.

<comment><USER6> This is an awesome idea by the way. I work in the energy industry and haven't heard about anything like this.

Just curious, it seems like with prior art, MDI would not have exclusive rights to the motor, right? Also their Wikipedia page says that they are currently using a design that was patented in 1990. Did you abandon this idea because of patent issues, or was it merely the lack of access to a proven/tested motor that stopped you?

<comment><USER4> It was getting reasonably efficient compressed air motors of decent size. The MDI docs claim they do about 50hp (or about 37kW). You'd probably want five or ten 'units' at that level (assuming the data center is 10 or 20MW like the ones Apple, Facebook, and Amazon have built).

You can of course run an existing steam engine on air pressure (I've done that with models) but they are optimized for a higher static pressure than the MDI engines target.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> this is a scam which has been explained a lot of time. energy storage density of compressed air is extremely small and will be enough for only a few miles of range, no way for improvement here, and efficiency is very, very low, way lower than batteries because of the energy inevitably lost when the gas heats due to compression, then dissipates heat. forget it.

<comment><USER8> And yet Tata are a huge, well-known international.

If they say they have an air-powered car, they have an air-powered car. This isn't just some dude in their garage.

<comment><USER9> The car apparently also has an electric engine. Did tata actually say the car ran on compressed air for the range specified in TFA, or is it just TFAA bullshitting?

Because AFAIK the effective energy density of CAES (Compressed Air Energy Storage) is 40~100kJ/kg depending on the tank material, with variable pressure. The upper range is roughly that of a standard lead-acid battery (except the battery has roughly constant voltage) and it gets completely blown away by e.g. li-ion (360~900kJ/kg)

<comment><USER7> worse than that, 'charge-discharge' efficiency is terrible compared to any kind of battery. it won't save any energy vs conventional car as measured in well-to-wheel efficiency.

<comment><USER9> Yes absolutely, I wasn't putting that in because the case was damning enough without involving the energy loss in charging the thing.

Though the comments suggesting the electric engine is a compressor to "refill" the bottles on the go could need that reality check.

</comment></comment></comment></comment></comment><comment><USER10> > a city car running on compressed air (as well as a battery-powered electric > motor)

The range sounds implausible to me at any reasonable speed on compressed air alone. How is the electric motor involved? Is the air a backup for the battery or vice-versa?

</comment><comment><USER11> Great when they finally will start mass producing this technology - <USER2> for large cities in India, Argentina and Brazil e.a where already lots of small vehicles run on compressed natural gas (CNG).

BTW - This story has been all over the I-Net the last days (again). A link to the actual manufacturer / technology company behind that. <http://www.mdi.lu/english/>

If such energy storage technology becomes available at low prices lots of additional "synergies" can be envisioned - e.g decentralized & cheap storage for small solar power (e.g. 50KW) - seen some DYI solutions for that with compressed air - overall the issue with compressed air storage is the low energy density.

<comment><USER5> CNG and compressed air are quite different. One burns to provide energy, the compression is just for storage. The other uses the compressed air as the power source.

They are not interchangeable, and having one doesn't help you with the other since the pressures are so different.

</comment></comment><comment><USER12> I hope this works - a compressed-air bike design from here (Uruguay) from 2005 failed to be funded, probably because the inventor was a bit of the crackpot type, but it did work.

[http://www.practicalenvironmentalist.com/eco-gadgets/air- bik...](http://www.practicalenvironmentalist.com/eco-gadgets/air-bike-shoots- around-for-15-miles-per-penny-but-unfortunately-looks-kooky-and-dangerous.htm)

<http://www.youtube.com/watch?v=05kQHmXfcQw>

</comment><comment><USER13> That's pretty awesome, though I wonder how they achieved that efficiency from simple compressed air (surely a pack of Li-Ion batteries of the same volume would do better?).

Regardless, you can compress air yourself all day long using solar panels and/or wind turbines, and even if you use the grid, it'll still come out a lot cheaper...

<comment><USER14> The proposed benefits seem to mainly be in the ease of deploying the recharging infrastructure, not greater efficiency. Here's a paper that's skeptical of the overall efficiency: <http://iopscience.iop.org/1748-9326/4/4/044011/fulltext/>

<comment><USER15> Interesting paper, and it suggests some other possibilities, including a Pneumatic/Combustion hybrid (i.e. using a compressed air "flywheel") which seems to have greater benefits than an Electric/Combustion hybrid (a tank of compressed air is lighter than batteries).

Perhaps Tata is experimenting with an electric/pneumatic hybrid (so electric, but compresses air when braking, and consumes it when accelerating). This might work, but doesn't help with infrastructure rollout.

<comment><USER9> > a tank of compressed air is lighter than batteries

Joule for joule, it's not. The _best_ compressed air tanks you'll find roughly reach lead/acid batteries in energy/weight (~100kJ/kg). Lithium-Ion batteries have 4 to 9 times the energy density.

<comment><USER15> Indeed. Also the mechanism to capture compressed air when braking would be in addition to the electric motor, which is needed in any event, and can charge batteries when braking. So yeah, upon reflection, just a Bad Idea.

</comment></comment></comment></comment></comment><comment><USER16> I love this idea, especially for short city-style commutes. The price ($10k) is good enough that it's under my impulse buying threshold for cars.

My only worry (confusion?) is if I brought this car into a small town and the car runs out of air, where can I fill it up? Can I just go to any car-repair shop that has a compressed air line (e.g. for hydraulics) and use their equipment?

<comment><USER17> > The price ($10k) is good enough that it's under my impulse buying threshold > for cars.

I'm not even sure where to start with this.

<comment><USER18> Your impulse threshold is about 3x my ceiling price for a car.

<comment><USER19> If your ceiling is $3333, maybe you should stick to riding a bus. Do you realize how much it costs to run one car for a year? Gas, registration, insurance, oil changes, maintenance, it adds up pretty quickly.

</comment></comment></comment></comment><comment><USER20> These would be great for city travel. The two main issues would be safety and parking. They'd have to make a strong case for the vehicle being safe in the case of an accident, not unlike the challenge the Smart Car had. For the issue of parking it would be unlikely that a city would set aside real estate just for these cars as they'd have to do it all over the city and it would be relatively expensive. I think a better solution would be a car-sharing one like Zip Cars. I can pay a monthly fee to have access to the cars at certain spots and if I want to leave in rush hour, I'd pay a premium, or something to that extent. It's a really interesting idea, I live in NYC and I'd love it here.

<comment><USER21> Did I miss something, why can't they use normal parking spaces?

<comment><USER22> I assume because the cars need to be charged while parked so you can get home.

</comment></comment></comment><comment><USER23> Mechanical simplicity and no expensive batteries are pluses.

<comment><USER16> I agree with you, to a point. I wonder about the mechanical simplicity of having air drive pistons in the engine. It's yet another point of failure and, while similar to combustion engines, is there no other way to have compressed air drive a car other than with a piston engine _?

_ I'm probably being naive here...I have no knowledge on this subject.

<comment><USER24> You could use a Quasi-Turbine. <http://www.howstuffworks.com/quasiturbine.htm>

</comment></comment></comment><comment><USER25> What happens in a car accident? I can't imagine the sudden expulsion of all that compressed air is going to act like anything other than a small bomb going off.

<comment><USER9> Some sort of quick-release valve as with LPG?

Not sure it's sufficient considering the kind of pressure you'll need in the tank to store an amount of energy worth using.

</comment></comment><comment><USER26> These have been cooking for a _long_ time. I was on the MDI mailing list back in 2000/2001 when they were supposedly coming to market the following year. It's cool to finally see them in production - I thought it might never happen.

</comment><comment><USER15> Leaving aside the laws of thermodynamics, well-to-wheel efficiency, etc.

Imagine getting stuck in traffic in such a car. What powers the A/C?

<comment><USER27> That's easy - the expanding gas!

Releasing pressurized gas absorbs heat so simply running the released gas through a set of A/C coils would provide indirect A/C or you could merely vent the "exhaust" (it is air, after all) into the passenger compartment since that "exhaust" should be very cold.

<comment><USER15> It's a cute answer, but very inefficient. You're throwing away the mechanical energy. Also bear in mind that "refueling" with compressed air will heat up your car.

<comment><USER28> The system overall may be inefficient, but using the cold exhaust from the engine as A/C doesn't make it any more inefficient.

<comment><USER29> In fact, if the air conditioner coils are between the air tank and the engine, the air conditioner could make it _more_ efficient, if you don't have some other kind of regenerator-in-a-dewar trick going on.

</comment></comment></comment></comment></comment><comment><USER30> It looks like this is getting completely owned by HN. Does anyone have a mirror?

<comment><USER31> I doubt it, it's hosted on tumblr. It handles far more traffic than HN.

</comment></comment><comment><USER32> I wish they published energy storage capacity in KW-hr. Theoretically a car can run for infinite distance once it has been accelerated to its desired speed.

<comment><USER33> No, a car can't run for infinite distance even once at its final speed, unless you're talking about the kind of theory that doesn't involve friction, drivetrain losses, aerodynamic resistance, or even things as simple as having a radio turned on (not to mention headlights)

<comment><USER32> Sure. These are practical things. And practically it can't.

<comment><USER34> Friction forces have been core theoretical concepts since many centuries.

</comment></comment></comment></comment><comment><USER35> search <http://www.tatamotors.com/search.php?query=airpod> shows 0 results !!

</comment><comment><USER36> It looks lame, like the Segway.

This seems to be the official teletubbie's car.

People wants something more akin a kiss ass compress air-electric kart to move in the city. Something simple, that does its job well, and fast when you need to accelerate in a hurry.

Cars are empty in the cities most of the time, make them unipersonal.

<comment><USER37> "Something simple, that does its job well"

Exactly. And isnt it what this thing is trying to do ?</comment></comment>


The Geographical Oddity of Null Island - <AUTHOR> https://blogs.loc.gov/maps/2016/04/the-geographical-oddity-of-null-island/ <comment><USER3> What geocoders use (0,0) as an error condition?

Outputting a valid value as an error flag seems like a pretty bad idea - <USER2> this actually common?

<comment><USER4> Extremely.

In part because the usual exceptional value, -1, is also a valid latitude and longitude.

<comment><USER3> Sure, but why not raise an exception? Or return a separate flag? Or even do something like (999, 999) (clearly not valid, at least for latitude)?

<comment><USER4> The 999 idea is good, but as for the other ones, oftentimes this data is recorded in, e.g., a spreadsheet, text file, or vanilla SQL table, so there's no way to throw an exception. You could store something like #N/A or NULL in the bad cells, but a lot of bad code and spreadsheet formulas will interpret that as 0 again, and then we're back where we started.

</comment></comment></comment></comment><comment><USER5> According to the Stockholm City Bikes app for iPhone, Null Island has been my permanent location since last May.

Unfortunately, there are no bike stations in the vicinity. It's lonely out here.

<comment><USER6> There was a town in my country that was bragging during the winter a few years ago that you could monitor all the slowplows in real time on the Web.

I checked the page, and sure enough it worked. On a hunch I zoomed out, only to see a couple of them parked on null island

</comment></comment><comment><USER7> Been there, bought the mug: [http://www.nullisland.com](http://www.nullisland.com)

<comment><USER8> I'm surprised you survived the smoke monster.

</comment></comment><comment><USER9> Uber always dropped me there when I started it (before I stopped using Uber for Lyft).</comment>


Ultrahigh Acceleration Neutral Particle Beam-Driven Sails - <AUTHOR> https://www.centauri-dreams.org/2019/01/03/ultrahigh-acceleration-neutral-particle-beam-driven-sails/ <comment><USER2> A 260-meter diameter magnetic sail weighing only 1kg would be quite fantastic to see. I wonder if something based on carbon tubes could withstand 100,000g. Acceleration at such levels would turn conventional metals liquid immediately.

</comment><comment><USER3> Dumb question: how do you couple to a beam of neutral particles?

<comment><USER4> From the article:

> The rapidly moving magnetic field of the Magsail, seen in the frame of the > beam as an electric field, ionizes the incoming neutral beam particles. > Nordley and Crowl discuss on-board lasers to ionize the incoming beam, > although this adds additional on-board mass and power

</comment></comment><comment><USER5> I like this idea. I was wondering if it would be possible to collect and focus solar wind close to the sun and use it as a high concentration beam.

Was also wondering if you could use the various gyroradii and charge of solar wind particles to "sort" them.

<comment><USER6> No. Any structure that could do that would itself be pushed by the wind. The energy/fuel needed for station keeping the focus unit would be better spent on the actual spacecraft ... unless you want some megastructure (ring) that wouldnt need fuel for station keeping.

<comment><USER7> Shouldn't there be some sort of "lagrange-like" point where the sun's gravitational pull balances out the push of the solar wind?

<comment><USER8> No, or at least not any stable such point, because the solar wind is not constant. Plus it is orders of magnitude less powerful than the sun's gravity. It's only usable (in theory) for navigation because any ship is already in orbit around the sun and doesn't need to "cancel out" gravity in the sense that wings provide lift to an airplane or a rocket achieves orbit from the ground, but rather it needs to be able to gently and continuously nudge itself into higher or lower orbits.</comment></comment></comment></comment>


Ask HN: What to do when you found out your co-worker earn 2x more than you? - <AUTHOR> We are doing similar work. And I would go on to say we are from similar schools and have similar past working experiences. <comment><USER2> Is he a freelancer and you a permanent employee? In my market it's quite normal for dev jobs to be ±5k perm and ±10k freelance. same exact job and skills

<comment><AUTHOR> same perm role

</comment></comment><comment><USER3> He asked for more. Simple as that. So you start working on your resume and on your next interview you set salary bar higher.

</comment><comment><USER4> When you have another chance to negotiate, don't forget about non-monetary forms of compensation. More vacation time, training budget, perks. Money isn't the only part, it's just one part of the whole picture.</comment>


Stop Using Std::endl [video] - <AUTHOR> http://articles.emptycrate.com/2016/04/18/stop_using_std_endl.html <comment><USER2> Don't optimize prematurely, especially since debugging time is a factor here.

If a long-running program crashes, a missing flush can be the difference between seeing or not seeing an important detail that preceded the crash. Instead of going straight to the cause, you might be wasting time exploring something that happened a bit earlier, or you may be forced to rerun the long program again to see the same issue with better logging.

Then there's the inconsistency aspect; if you become used to "\n", and see it "work" all the time for streams that happen to go to the terminal, you will be confused when "the same" thing does not have the same behavior for a file stream. Use the abstraction ("endl") until you know you _need_ it to be different.

<comment><USER3> Working around a broken API is not premature optimization. Stroustrup et al. point out the same problem with std::endl[1] and advise the same remedy as the presentation linked here. Conflating EOL with flush() was a mistake the moment it was first written.

Systems programming languages aren't about easy troubleshooting. C/C++ APIs should be performant by default because when they are not we end up working around them, often badly. If I want the stream flushed I'll configure it to behave as such or I'll call flush explicitly. Any other mindset belongs in Python, Java or some other higher level language.

[1] [https://github.com/isocpp/CppCoreGuidelines/issues/357#issue...](https://github.com/isocpp/CppCoreGuidelines/issues/357#issuecomment-153515258)

<comment><USER2> I'm not defending the implementation (I hate most of std::iostream), just that "\n" is not exactly equivalent so switching to that may cause surprising behavior and create problems. Auto-flush has its uses.

If the main purpose of a program is to generate output then it ought to know what it's doing anyway and know how to avoid poor performance. For _most_ programs, I'd say that Unix rules of thumb apply: if you are already trying to be "silent on success", your program will either print nothing or maybe an error or two and not have to worry about print performance. If your program might only print one error and that doesn't even show up because a flush didn't happen before a crash, there is a big problem.

</comment></comment></comment><comment><USER4> TLDR: std::endl causes a flush of the buffer to the file for every new line, vs "\n" or that doesn't. Flushing the buffer for every new line is costly, and will slow down your file write.

My addition (which might have been in the video, didn't watch it all): Don't worry about \r\n vs \n, if you're on windows outputting \n will convert to \r\n, as long as you opened the file in text mode.

<comment><USER5> Personally I use \n for line endings regardless of Windows or not. notepad.exe can't understand \n and displays everything on one line, but everything else can.

<comment><USER6> I've completely given up on Notepad compatibility. I can only assume that the reason Notepad in 2016 can't handle '\n' is due to pure spite by someone high up inside Microsoft, Hanlon's Razor be damned.

The sad part is it's not even just Notepad. It's the underlying "EDIT" HWND class itself. So anyone coding in raw Win32 APIs has to basically capture paste events from the clipboard to transform text into the "\r\n" state, and upon reading text out of it, potentially convert it back to "\n".

Probably a five-line patch to that class would eliminate so much extra work for developers. And we could drop the whole ridiculous "text mode" for working with files while we were at it.

Plus I'm sure there must have been thousands upon thousands of external requests to Microsoft to be able to use Notepad with all their non-Notepad text/configuration files over the years.

It's hard to believe this is anything but very deliberate at this point. Add to this, the mess Microsoft perpetuates with not supporting UTF-8 (std::wstring, wchar_t, _wfopen, non-standard iostream extensions for Unicode filenames, etc), and one really begins to have a deep seething hatred for Microsoft.

<comment><USER7> That's like asking why does Windows use \ instead of /. It's not hatred, it's just... the way things work. Changing it would be very costly and would create compatibility problems for decades presumably, so why do it?

<comment><USER6> \ vs / is an interesting example. fopen() and family from MinGW _can_ use / in paths on Windows. I use that feature all the time. cmd.exe can't, and I understand that would break things due to the use of / instead of - for flags in the Windows world.

Whenever it comes to something programming-related that might improve code portability between different OSes (C99, LF, UTF-8, etc), there's a mountain of after-the-fact justifications for why it would break backward compatibility and other such tripe.

But honestly, what would making "EDIT" accept "\n" alone do to break backward- compatibility? "\r\n" would still work, of course. Is there a group of people inserting stray "\n"s alone into text files, and expecting Notepad to silently ignore them and dump all of that text onto the same line? If so, those people are absolutely horrible :P

But okay, fine. Require a program .Manifest flag to opt-in, then another special ES_ACCEPT_LF flag with a caveat that it's Windows 10+.

Even all the people that have jumped through hoops with things like hooking paste operations to transform "\n" into "\r\n" for "EDIT" ... that would still work just fine, it would just be unnecessary.

The only cost would be that there's a short time where people are trying to use these "\n" only text files on older versions of Windows. But we've been dealing with the fallout of that _anyway_ for the past 21+ years now.

You can't possibly tell me that supporting "\n" alone is an immense burden for a company with as much money and developers as Microsoft. No, I'm sorry, but this, C99, UTF-8, things like _wfopen, WSAPoll over poll, etc are all very much intentional: they're designed to maximize vendor lock in. Microsoft doesn't want your code easily moving between Windows and Linux. Even though they're a convicted monopoly with a mountain of evidence of their abusive actions, they still have so many white knights ready to defend their actions as benign =(

<comment><USER8> IIRC, '/' as a path component separator works just fine in every Windows API call that matters that takes a path and (unless I'm remembering wrong) has for a _really_ long time. It works just fine in Windows 10's version of Windows Explorer. I would be surprised if it didn't work in W7's Explorer, too.

CMD.EXE is -sadly- a bucket of suck.

> ...WSAPoll over poll...

Don't fucking get me started about the WinSock API. >:(

</comment></comment></comment></comment></comment></comment><comment><USER9> You can use C-library functions in C++, so just use fprintf, and you can flush however you see fit. I've been writing C++ since basically forever, and find the streaming operators in C++ to be way too much of a pain. It's doubly painful if you ever consider internationalizing your software.

fprintf(fd, "Number: %.3f\n", number)

Is a whole lot easier than

std::streamsize ss = std::cout.precision(); std::cout << "Number: " << std::setprecision(3) << number << std::setprecision(ss) << std::endl;

Since setting precision is modal, you have to set it back if you don't want to screw up future output.

Streams suck!

<comment><USER10> One thing that streams have that the c routines don't is type safety and overloading for user-defined output.

Also take a look at cppformat for some of the best of both worlds.

<comment><USER9> Yup, cppformat is nice. I could also have a nice type-safe wrapper around libc functions. It doesn't change the fact that the API in the language is tedious.

When you're doing internationalization, a common thing you might do is something along these lines:

fprintf(fd, translate_string(context, "Result %d of %d"), num1, num2);

The translation may be "%d of %d results" in another language. It's really difficult to map that into streams.

Yes, I'm over-simplifying, since you can't have arbitrary placeholders due to order differences between languages, but it's _much_ harder to write simple code with streams than libc, and I stand by that!

As for user-defined data, I've added .toString() functions on objects which I can call whenever needed, either from the ostream operator or pass the result to libc.

</comment></comment></comment><comment><USER11> Also interesting to note is that as opposed to std::cout; std::cerr (associated with stderr) is automatically flushed, and that std::clog (also associated with stderr) is not automatically flushed.

[http://en.cppreference.com/w/cpp/io/clog](http://en.cppreference.com/w/cpp/io/clog)

<comment><USER12> I guess it's fitting that something called "clog" does not automatically flush. :-)

</comment></comment><comment><USER4> One case where you would want to use endl and not \n is if you're outputting to something like a log file that's being monitored with tail -f.

</comment><comment><USER13> This is part of the coding standard for LLVM for years: [http://llvm.org/docs/CodingStandards.html#avoid-std- endl](http://llvm.org/docs/CodingStandards.html#avoid-std-endl)

Of course if you're debugging you want to flush ASAP.

</comment><comment><USER14> no. you put that thing in the language. fix the language. This kind of nonsense is why people don't like using c++, I remember Qt had a similar thing with QThread. They published a popular article called QThread you're doing it wrong, and it turns out their own documentation was doing it wrong.

<comment><USER15> endl is not broken, and does not need fixing. it's one of several ways to do things and this video is pointing out that its _documented_ features may not be exactly what you want, and alternatives are available.

However, sometimes endl is indeed what you want. There is nothing to "fix" here, except maybe your attitude.

<comment><USER16> I think there's a valid argument to be made that it is at least poorly named, and that naming has resulted in people using it wrong, including among people who teach the language and so compound the problem.

<comment><USER17> Agreed, names are the first line of documentation. Having endl flush is like using single letter variable names, but maybe a bit worse since single letter variables make you go find where they were declared but this lulls you into a false sense of security.

This violated the principal of least surprise enough that someone made a 10 minute long video on it :) It's really hard to blame the user this time.

<comment><USER18> People not using descriptive names for the important stuff is probably my number one pet peeve. We're not on a VAX, bytes aren't precious, and we aren't naming terminal commands, keystrokes aren't either. And nowadays every editor has autocomplete, so there's really no excuse.

<comment><USER17> The great vowel shortage of the late 80s is finally behind us :)

</comment></comment></comment></comment></comment></comment><comment><USER19> Or, stop using C++

<comment><USER20> Yeah, I'll just go convert the LibreOffice codebase to Go right away.

<comment><USER21> Finished already? I have a JVM that waits to be converted, so I can be sure that no C++ pollutes my Java code. Kidding aside, I'm still curious if Rust/Go (or whatever) will be serious contenders to develop current c++ codebases further, e.g. the old code stays c++ but new code will be written in something else.

<comment><USER18> Rust is probably more appropriate for that, since (like C++) it uses system APIs directly instead of importing a runtime.</comment></comment></comment></comment>


How dinosaurs got Wufoo's investors a 29,561% return [video] - <AUTHOR> http://community.uservoice.com/blog/kevin-hale-wufoo-userconf-2012-video/

<comment><USER2> So, if the JOBS act was around when Wufoo was taking investments, and I would have invested $1000, I'd have gotten back $295,610? Certainly something to think about...

</comment><comment><AUTHOR> FYI dinosaurs are at 05:08

</comment><comment><USER3> When's my talk going up :-P

<comment><AUTHOR> I think it's scheduled for next week. :)</comment></comment>


Ask HN: Is it possible (legally) to have a cofounder without incorporating? - <AUTHOR> Situation: I am broke and in a smaller market(RI) and have limited "professional" experience. I am a pretty capable developer so I am not worried about actually setting up, branding and launching the venture or doing the actual contracts. It will simply be a small portfolio site and some email addresses, etc just a virtual company. I have been doing contracts that are structured from person/entity I am dealing with => me.
I have been looking for another dev. to help share responsibilities with and who would have a complimentary skill set. I am a full-stack JS dev and capable with RoR s/he would be php/mobile so we could provide a full service agency.
I have owned the domain for a couple months, and the mail servers are hosted by zoho.com and set up with basic functionality(i.e dev@,hello@,hr@ ) etc.
If I bring someone else on, especially since the company is unincorporated, I will be taking on liability. I was going to just structure the contracts company => both of us in a 50/50 split, but things like ownership of code, ownership of the website, breach of contract are concerning me.
The cofounder would be a stranger, further complicating matters. Does anyone have advice on how to protect myself with contracts instead of incorporation? I want to continue to take contracts and expand but don't want to tie myself to a stranger/be open to a personal lawsuit. Obviously this isn't like a YC level startup, I literally need to generate like 60K a year, even before the split, to just pay bills. <comment><USER2> Yes, through a partnership agreement. Your lawyer can probably draft an agreement for you, or there are services online where you can purchase template partnership agreements I believe.

However, the cost of incorporating is really not that high in most countries. In the US, and most of Europe they can be formed in a week for less than $500. I would highly recommend it.

<comment><AUTHOR> Mark thanks. I appreciate it. Can't hire a lawyer but just wanted to see if this was somewhat common. I'll find an example and ammend it. Cheers.</comment></comment>


Ask HN: How to immigrate considering my "circumstances"? - <AUTHOR>

Developer/programmer here.
By circumstances I mean: wife and kids, age, skills.
I live in Brazil and I really would like to leave this country and definitely live in another place. I don't have any preferences for the place right now and I accept suggestions.
My main issue on immigrating is to be accepted given my age (37) and family. AFAIK, having an effective job proposal and employer sponsorship is the only way for many countries. Do you know anywhere where people can go on business or as tourist and apply for jobs? <comment><USER2> Don't see why your age would be a problem for immigration. For many western countries, academic/professional qualifications and financial capability (especially if applying for investor visa) matter more. I believe Canada also has a points system where you can apply to immigrate based on your qualifications without necessarily having a job lined up.

Why do you want to emigrate from Brazil? Listing some reasons would enable people to give you better country suggestions.

Mentioning your technical skills here and including some type of contact info in your profile would also be useful for anyone interested in contacting you in regards to employment.

<comment><AUTHOR> Thanks for replying.

I decided in this question to focus on what I regard as obstacles to enter on another countries or finding a job. That's why I avoided talking too much about myself professionally.

The reasons I want to emmitgrate are basically the same as the ones this guy described: [http://amatarazzo.tumblr.com/post/79624842882/bye-bye- brazil...](http://amatarazzo.tumblr.com/post/79624842882/bye-bye-brazil-its- with-great-sadness-that-i). I disagree on some views, but he is almost 100% correct.

On my skills, I prefer not to talk about this now, as I'm interested on understanding how the process would work. I would say I've been in the workforce for more than 12 years, and have done a little of a lot of things.

Thank you again.

<comment><USER3> > I decided in this question to focus on what I regard as obstacles to enter > on another countries or finding a job.

That's the wrong approach. In most countries you'll need a job before getting a visa, so focus on job market research beforehand, then check the visa obstacles.

Unless, of course, you don't need a job because you have (loads of) funds to apply for a entrepreneur kinda of visa.

If you have never lived outside your own country, I suggest you write down a list of questions you might have and then ask them around. You might have better changes to get them answered that way, instead of generic stuff. Immigration is highly subjective, by which I mean it depends a lot in people's particular circumstances as much as in foreign laws.

</comment></comment></comment><comment><USER4> You can go to almost any country as a tourist and apply for jobs. Just don't mention this in your visa application or they will refuse your visa.

Once you have an employer willing to sponsor your H1-B / visa / work permit, you can go through the immigration process and move with your family.

<comment><USER3> Bear in mind that some countries (i.e. UK) will not allow you to change visa categories while already in the the country. You must leave and apply for a new visa from your home country.

Example: in the UK if you hold a valid student visa (Tier 2) and find a company willing to employ you based on your expertise (Tier 2), you must to go back to Brazil and apply for a visa "Tier 2" from there and then come back to the UK.

<comment><USER3> Edit: _student visa (Tier 2)_

student visa _(Tier 4)_</comment></comment></comment>


Some books for November - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2009/11/some-books-for-november.html <comment><USER2> I wonder how much money Seth makes on creating simple lenses like this with Amazon referral links. I bet it's a decent amount.

Some interesting books on there nonetheless.

<comment><USER3> "sethgodin donates 100% of this page's earnings to charity. You can do it too..."

Just follow the link.</comment></comment>