Ask HN: Should one buy the N1 ? - <AUTHOR>

I admit, I have a crappy old phone (SonyErW910). Everyone seems to be running around with shiny new iPhones. But I can't figure out if the N1 is really worth it.
Has anyone used the Nexus One ? The reviews about it appear to be divided.
Or would you recommend going for Droid/iPhone ?
Thanks
*Disclaimer: This post was not A/B tested nor optimized for maximum viewing. <comment><USER3> I've had my Nexus One for four days now.

The hardware itself is outstanding. The screen is gorgeous, I like the haptic feedback, and there are lots of nice touches like the trackball that lights up.

The software has a few great points too. The voice recognition is incredible. I like having the choice to run background apps.

This is also my first Android phone. After hearing early complaints about the OS, I thought I'd put it off until it's fully baked. The fact 2.1 was touted as a great OS update gave me the feeling it's time to try it out.

Well, I can say there are a lot of annoyances that are piling up.

Scrolling, especially flick scrolling, is inferior to iPhone 1.0. It's jerky and fickle.

The onscreen keyboard feel less accurate. I don't mean the predictive typing, I mean the prediction of what keys I'm trying to hit.

Navigating text fields is bad. When the voice recognition gets one word wrong, it's a pain to go back and fix it.

No multitouch. This is a pain in maps or zooming in on a web page. I know there are patent concerns, but as an end user, I don't care.

In general, I feel like the OS is half done. Someone cranked out a feature and performed zero refinement. I have to load a submenu to stop loading a web page? I would sacrifice wizz-bang features like voice recognition to fix all these little annoyances.

I'm going to give the phone a few more days. If I still haven't adjusted, I'm selling it.

<comment><USER4> Specific response:

> I have to load a submenu to stop loading a web page?

The icon up by the location bar doesn't turn into an "X" for you while a page is loading? (When the page is fully loaded, it's the bookmark icon; when the location has focus, it's a search icon. This is on the Droid, though.)

In general: your points might be right, but it's also tough to tell how many of them come from being used to the iPhone, vs what your experience would be like coming from a blank slate. I'm certain some of that comes from falling short of Apple's high usability standards, but I'm also certain some of it may just be that you've gotten used to The One Way To Do Things. ;)

I've never used the iPhone but in the few weeks I've had a Droid, I've been annoyed very rarely and impressed more often.

<comment><USER3> I just tested.

I loaded a web page I'd bookmarked on my home screen. The top part of the screen shows the loading bar. The bookmark button is still a bookmark.

When I click a link, it doesn't change into a stop button until the actual page has started loading.

But it looks like loading the bottom menu shows me stop consistently.

The "you're just not used to it" argument constantly rears its head when people criticize usability. That's why I was careful in pointing out the deficiencies.

I can understand that the keyboard takes adjustment. Notice I didn't criticize the android "word menu" auto-complete.

The poor scrolling is a technical failure. Nobody wants jerky scrolling.

And the lack of pinch-and-zoom has repeatedly been covered as a patent issue, not a UI choice.

"You're just not used to it" is extremely dangerous reasoning.

<comment><USER4> > "You're just not used to it" is extremely dangerous reasoning.

I wasn't quite trying to say exactly that, at least not in a blanket manner.

But, let's take scrolling as an example: I haven't noticed that the android scrolling is jerky, not even a little bit. This is probably because I've never used something as silky as the iPhone. ((Or, perhaps, if I did try an iPhone, I would find its scrolling _too_ smooth with no satisfying 'thump to a stop' at the end of a scroll or 'jump into motion' at the beginning.))

In other words, it's not "You're just not used to it" -- it's "without the other point of reference, would you even notice it?"

<comment><USER3> Your line of reasoning flawed, in that it can be applied to anyplace where one option surpasses the other. Without a car as a point of reference, would you notice a horse and buggy are so bad?

Yes, I would live with the scrolling on the Android, because I'd say to myself, "That's pretty good for a mobile phone." However iPhone 1.0's scrolling was vastly superior to today's Android. That's over two years ago. I think it's safe to declare iPhone 1.0 as the bar.

And, again, I'm not criticizing the thump-to-a-stop behavior. I'm criticizing the frame rate and responsiveness.

<comment><USER4> I'm not going to say you're wrong, because I'm not really in a position to argue that. However, we're talking about Volkswagen vs BMW here, not horse and buggy vs car.

</comment></comment></comment></comment></comment></comment><comment><USER5> I've had a Nexus One for a few days now as well (ordered on launch day) and I can say that it's a fantastic device. The aura of excitement I had with the experience on my first day owning it was akin to the one I had after coming out of the IMAX 3D theater after seeing Avatar. It's just _cool_. Let me elaborate.

I'm a Mac nerd. I hack on my mac, I worked at an Apple store for a couple of months for fun, and I really believe that they have their shit together and produce magnificent products. I never owned an original iPhone, but had a 3G the day they were released (see a pattern, like many of you I am a gadget freak).

I eventually just got bored with it. It's a _great_ device, but like I said I'm a gadget freak so I needed a new fix. Android was an attractive platform because of it's tight integration with Google (I'm an apps user), and T-Mobile offered much cheaper plans. My girlfriend is also on T-Mo, so the path was clear. I bought my first Android device in October of 09, a T-Mobile MyTouch 3G. It took a lot of getting used to. I figured that since the iPhone was the gold standard for smart phones, a lot of the Android experience would be a copy and therefore I'd learn it quickly. Sort of... but no. Unlike the iPhone, there are many devices running Android and most of them have a lot more external buttons. The UI depends on it. The back button for example, and the menu button, are critical on Android. Being a UI guy I learned things quickly, and after hacking and tweaking the phone with Cyanogen's mod, I came to like it. I missed my iPhone though, and longed for a better android experience; especially after the Droid came out, running Android 2.0. Unfortunately I had unlocked my iPhone and given it to my girlfriend, so I wasn't about to take it back.

Enter Nexus One. I had known about the physical device for a long time. Most people referred to it in the HTC community as the Passion. I was pretty damn excited when the Nexus materials started to leak. The device was gorgeous, and the specs were fantastic. I quickly sold my MyTouch on Ebay and bought the Nexus as soon as I could.

Best $530 I have ever spent, by far. The new OS is an amazing improvement on the old. The experience has almost done a 180. Everything is smoother and quicker. Things are more convenient and not as convoluted as they once were. I'm sure the 512MB of ram and 1GHz processor have a great deal to do with that, but I'm not complaining. The hardware is gorgeous too. It feels great in your hand (much like an iPhone) and like many say the screen is beautiful.

I've never owned a Droid but I've played around with one. I don't like the hardware keyboard and the device is slow. It doesn't have the OS that the Nexus has (2.0 compared to 2.1) and there's a big difference. The snapdragon processor is amazing. This thing screams compared to a Droid! Unfortunately... if you're on Verizon you have to wait a while for the CMDA version... but it's worth it! The Droid was a great effort, but it's not as nice as the Nexus.

tl;dr - I went from iPhone to Android (with a MyTouch 3G) and was unimpressed. I'm a UI guy so I'm real picky. I just got myself a Nexus One, and I'm finally able to say that the Android experience is on equal playing field with the iPhone. No other Android device can say that, except the Nexus One.

<comment><USER6> "like I said I'm a gadget freak so I needed a new fix"

I'm the same way Michael.. I've owned the iPhone, 3G and now 3GS.. and I'm getting bored with it. But there are a few apps I've grown to love and can't be without (iKindle is one of them) so I will be sitting tight for a while.

<comment><USER7> How in the world does anyone get "bored" with an iPhone, or any other current- gen smartphone for that matter? Adult ADD? There may not be an app for that, but I'm sure there's a prescription.

<comment><USER8> Gadget freaks are not like you or me.

(What's funny is that most of my acquaintances think that _I_ am a gadget freak. I, who own an original 2G iPhone! By the standards of the true gadget freak I am a hopelessly mundane fuddy-duddy.)

What you have to realize is that an actual operating gadget that one uses from day to day is a disappointment to gadget freaks. I suspect that a gadget freak's favorite moment is the one right _before_ he or she opens the box... the moment when the device is fully alive in the imagination, the moment before one's dream collides with the drab reality of the actual world and the inevitable letdown begins. That, I hypothesize, is why there's such a fetish for "unboxing" videos.

<comment><USER9> 30, 40 years ago, there were a lot more guys out in their driveway working on some old car on an average Saturday afternoon. Those folks [and their modern counterparts] need something to do.

<comment><USER7> This is more like going down to the dealership every Saturday afternoon and buying a new car, just for something to do.

Fun stuff if you have the cash, I guess!

</comment></comment></comment></comment></comment></comment><comment><USER4> I moved from a crappy old phone to the Droid, and am quite happy with it.

No matter what you end up with, I'd say that the differences by upgrading far outweigh which particular 'cutting edge' phone you end up going with.

I didn't think much about the transition -- just aiming to phone and portable web browser. In less than a month, though, it turns out I've got:

\- a suprisingly decent point-and-shoot camera, as long as it's not dark

\- a hiking/biking/skiing GPS

\- a car-nav GPS

\- a guitar tuner

\- barcode scanner & product nutrition database

\- portable music/video library

\- and more! ;)

Really, it's a general purpose computer that happens to be bristling with both sensors and telephony capabilities, and an almost always-on connection to the internet. Regardless of whether it's 95% as slick as it could be and more 'open' (Android) or 98% slickness level and less 'open' (iPhone), they're still pretty much equally revolutionary.

(N.b. as a developer it was _very_ nice to be able to write software for my phone from day one, without having to jump through a ton of hoops.)

(Edit for bullet points.)

</comment><comment><USER10> i've had every iphone, the google adp1 (g1), mytouch 3g, nexus one, nokia e71, blackberry curve, blackberry bold, blah blah blah. i hate all of them. i use whichever one i hate the least, until a new one comes out. i try it, find things that bother me, sell it, and repeat.

my only advice is to try the phones yourself (preferably without having to buy them) and see how you like each one. go to a store, find a friend with one, whatever. but try them yourself without having someone standing there trying to "sell" it to you (literally or just trying to get you to get what they have).

these modern smartphones are so complex and powerful that asking for someone's opinion is like asking "what kind of car should i buy?" there are things you may like about a particular phone that others hate. there are things that will matter more to you than to others. you may require some functionality that someone else doesn't, and vice versa.

<comment><USER11> _i hate all of them_

Wow, I find that surprising. Smart phones are just incredible pieces of technology, and have made my life a lot more convenient in lots of little ways. Obviously there is tons of room for improvement, but I think you'd have to be pretty jaded to truly "hate" any of the smart phones. (Value-for-money is another question, but you can always choose not to buy one.)

<comment><USER12> Actually, I've hated all the smart phones I've used. Typing on a cell phone is, to me, a really inefficient time suck that people don't notice because they're used to it.

Fundamentally, I just want to make phone calls on my cell phone - <USER2> everything else I want a laptop with a 3g card.

</comment></comment></comment><comment><USER13> Does T-Mobile provide good service where you live, work, drive, and play? If not, don't get a Nexus One. (assuming you're in the US.)

Android vs. iPhone is a religious debate, and it's unlikely you'll receive enlightenment from flames. Android 2.X (N1, Droid) is a big improvement over Android 1.X (everything else).

<comment><AUTHOR> Thanks for the input

I am not from US and we have excellent GSM coverage here.

The Droid's keyboard sounds like the big winner. Especially with all the stuff about no multi-touch on N1.

<comment><USER14> If you have any servers that you SSH into regularly, I highly suggest getting an Android phone with a keyboard. ConnectBot (a SSH client for Android) is the reason I got my G1.

<comment><USER7> Counterpoint: the iPhone is God's own portable VNC client. Using any kind of remote-desktop functionality without pinch-and-zoom sounds painful, unless other phones have a clever UI paradigm I'm overlooking.

If you're mostly interested in command-line work over SSH, though, I can see how a phone with a physical keyboard would be the best tool for the job.

</comment></comment></comment></comment><comment><USER15> I don't think you can go wrong with any of these three, but I went with the Droid. Reasons:

\- Better screen than iPhone

\- Physical keyboard

\- Verizon service (I guess this doesn't apply as you aren't in the US)

There's no question that the iPhone OS is slicker and easier to use, but the Droid lets you do more at once.

I'm not sure why you'd want to go with a Nexus One right now. Droid is about the same price, gets better network coverage (clearly that will change when the Verizon N1 comes out), and has a keyboard.

My only real complaint with the droid is that I wish the microphone was a little better. It's possible that the Nexus One has that advantage with their two-mic noise control system.

Edit: iPhone's biggest advantage imo is the app store. Android Market just isn't there yet.

<comment><USER5> I think that part of the reason why the apps for the iPhone are better is due to the Android platform in general. No one codes Java for fun or for cool points. You don't see companies popping up like Tapbots where the UI's are carefully constructed pixel by pixel for Android. The coolest thing to hit Java for a long time is Clojure, and that's only for data nerds.

The mac is cool, OS X is cool, developing for the mac is cool. That's why people like the iPhone. It's _cool_. People want their shit to be rad, and they want others to think that they are rad too. You don't get this with Java, so I don't think we'll ever get this on Android.

Suffice to say... I have a Nexus One (previously I had a MyTouch 3G, and before that an iPhone 3G) and I love it!

<comment><USER16> I think Android is heading in that direction, though. Clock, Car Home, and the new Gallery application all show signs of a potential new direction for the Android UI, and it looks _good._ Gallery in particular: Check out what happens when you hit the share button in the app. It's a very Mac-like look and feel.

<comment><USER5> Very good point. I've noticed all these things and really like them. I like how Google has kicked it into high gear and I hope that independent developers do too. I think we need a better UI framework or just app framework in general for building Android apps... I'm not satisfied with the way things work right now.

</comment></comment></comment></comment><comment><USER17> Well I had you beat in terms of crappy old phone ownership. I just upgraded from my good old Sony Ericsson w800i (had it for ~3 years) to an iPhone 3GS. I thought long and hard about this move, I've seriously pondering upgrading my phone for about 3 - 4 months now. I finally went with an iPhone mainly for two reasons:

1\. I bought myself a Mac desktop last year and I love it. I felt the iPhone would compliment nicely.

2\. They've had a couple of iterations to sort out the kinks in the iPhone now and IMHO it shows.

The 3GS feels very polished to me and I don't regret my decision. I've only had my iPhone for about 10 days and I already have Google Sync set up for email/calendar syncing, I've used it as a Skype VoIP handset (in conjunction with my home Wi-Fi), I've got games on my phone that are actually worth playing, mobile Internet access that's actually practical to use and I've got an awesome remote for use with the VLC media player.

I've even made a few phone calls.

I really thought about getting one of the slightly less mainstream phones that might give me more "geek cred" or something. But in the end, I just want as good a user experience as possible and I felt I would get that from the iPhone. YMMV.

Granted, upgrading from a SE w800i I probably would be more than happy with any of the current generation of phones and I can't directly comment on the N1. But all my research led me to the conclusion that if you're looking for polished, go with the iPhone. If you're wanting a little more bleeding edge and experimental, go for one of the other options.

</comment><comment><USER18> I have both an Android handset and an iPhone 3G. Both are _good enough_ for e-mail, browsing, texting, calendar and all the fundamental stuff you'd expect from a modern SmartPhone. So whatever choice you make I don't think you'll be disappointed.

My personal preference is still the iPhone for a variety of reasons. The biggest one is the UI is entirely touchscreen driven. Android phones have 4 or more physical buttons so as you're using the phone you have to switch between the touchscreen and buttons. It may not seem like a big deal but I find it makes most applications less obvious to use since they don't have to represent all their features on the touchscreen where my attention is focused. Sometimes I have to remind myself there are 6 buttons on my Android phone and explore what each one does in each different application. Lots of functionality is revealed when you use the Menu button so I frequently have to stop using the touchscreen, hit the menu button, and go back to using the touchscreen again. It's not hard to find and press the menu button, it's right there, but it interrupts the flow of what I'm doing and I don't like that.

</comment><comment><USER19> What do you want to do with your phone? This is the important question. If you are just using it to call people, send messages, browse the net... so you don't need an expensive one.

Precise what you need and then decide each one to choose

</comment><comment><USER20> I've been using it since mid-December and really like it. It's sleek, it's fun, and it has some nifty features. I love the voice recognition, I love that they fixed the Webkit bug that prevented me from browsing HN while logged in, and I like that "unlock screen" is now a slide-right gesture instead of a button, which virtually eliminates pocket-calls and embarassing MP3 plays.

Battery life could probably be better - it seems to be about on par with the G1, maybe a little better. I get about 4-5 hours of heavy game playing or navigation/GPS use, 2-3ish days on standby.

</comment><comment><USER21> I would recommend neither of the three phones mentioned, but HTC HD2...in my subjective opinion, having the 4.3" screen, with other things being similar, could make it a best option. If you are from USA, I suggest you wait for it.

<comment><USER22> Ah, windows mobile, combining the usability of Android with the joyful development experience of the iPhone. Who could ask for more?

<comment><USER21> But you don't see much of WM there. There is one software layer above WM, HTC Sense.

</comment></comment></comment><comment><USER23> Are you asking if you need mobile internet?

Would be interested in answers to that, too. I haven't joined the fun yet, but I wonder if there really is anything life changing about it (yet)?

<comment><USER15> The best thing for me is that you don't have to worry about getting directions or knowing where you're going to go. There's also the ability to instantly pull up info--you never need to forget who that actor was, and discussions don't get derailed by pointless quibbling over facts that could easily be looked up.

And yes, you can browse HN on the toilet. Life is good.

</comment></comment><comment><USER24> I originally read the title as "Should someone by H1N1". Oops.

</comment><comment><USER25> The N1 is going to be crappy, just like the original iPhone was crappy. If you want to support the Droid movement, buy the Nexus. If you are willing to wait a while for your phone not to suck, buy the Nexus. If you are blown away by speech to text, buy the Nexus.

If you want the best current smartphone (and AT&T works in your area), buy an iPhone.

<comment><USER26> We need to make a distinction here. Are you saying the N1's hardware will be crappy, software will be crappy, or the interaction between the two?

The Android software has been in the wild for more than a year now and it's pretty well developed, so it's not accurate to compare that to the original iPhone software. The N1 hardware appears to be top-notch so I think the word crappy applies even less to that than the software. So then I guess you are saying the N1 will suck for awhile until they work out problems with the interaction between the hardware and software. That's a fair criticism I guess, although I think unfounded.

I can tell you that this phone does not suck. My girlfriend works at Google so I've played with this phone since the beginning of December. It is most definitely the best smartphone on the market right now. I'd say if T-mobile has a decent presence in your area you'd be a fool to go with an iPhone over an N1.

<comment><USER25> 1) The hardware is nothing without the software. Even a nice capacitive touchscreen needs the right programming. So, I don't think I really need to draw a distinction here. Also, I think everyone is using roughly equivalent, commodity hardware.

2) All Droids lacks the wealth of apps the iPhone has.

3) All Droids lack years of market testing like iPhones have.

4) If your girlfriend works at Google, you are certainly biased, and I think anyone who has touched all the major smartphones can't really say any of them are the best except the Blackberry or the iPhone, depending on the application. All Droids and Palms are just me-toos trying to catch up right now. I'm not saying Android and its phones won't get there, they just can't be there yet.

<comment><USER26> I'm mostly trying to point out that the N1 is not a new phone in the sense that the original iPhone was, and your entire first post indicates an overly simplistic view of the phone and its software. When Snow Leopard was released and started shipping on new Macbooks (with newer hardware) it would have been ridiculous to suggest that this "new computer" was "too new" and will suck for awhile thus we should wait a couple of iterations.</comment></comment></comment></comment>


Project started to run Erlang on bare metal - <AUTHOR> http://kerlnel.org/ <comment><USER4> Don't announce your project until you at least have something going. The empty repo at <https://github.com/kerlnel/kerlnel> ? That should at least have enough code in it to boot _something_ , even if it's just a "hello world!" that doesn't have anything to do with Erlang. Getting a build system in place and developing some sort of contribution guidelines are also important.

There are major advantages to keeping your grand projects in stealth mode for a while. For one, it's good to wait until you have instructions for even the dumbest ADD teenager to compile and run the thing, or else you'll have to deal with a flood of endless terrible questions. For another, it doesn't exactly inspire confidence to come out and say, "Hey, we want to run Erlang on bare metal, we have README.md, please contribute!"

I fully acknowledge that the creators intended to wait longer and that bandris may have just come across an interesting looking Github repo, but even that proves a point: Your repo should be private until you have something to show. When Linus announced Linux, he already had code running in userspace, with bash and gcc ported!

Edit: I say this having been involved in projects that announced too soon. It's important to establish something concrete first.

</comment><comment><USER5> It's an exciting idea. Why should server software run on OS's designed to let you play Tetris or compose emails at the same time? It's not like you get all that for free. In theory, specialized apps have a lot to gain from running on more specialized platforms. There ought to be more experimentation in this area.

The name "Kerlnel" is going to be a problem, because it's so awkward to say out loud. You don't want your name to be difficult for people to say; you want them saying it. "Kerlnel" is a clever pun but that doesn't last beyond the first time you read it.

<comment><USER6> > specialized apps have a lot to gain from running on more specialized > platforms

Guess there could be some gains, but a lot? Enough to bother with?

What about hardware support?

<comment><USER5> _What about hardware support?_

Quite so, hardware is the holy grail. (Alan Kay: "People who are really serious about software should make their own hardware.") I dream of a golden age of experimentation in vertical stacks: specialized hardware designed for specialized classes of application with only so much OS as is needed to support them. Perhaps if the cost of developing hardware falls the way the cost of developing software did, we might see something. Why not an Erlang machine? A Lua machine? A spreadsheet machine?

 _Enough to bother with?_

Order of magnitude is table stakes for interesting, wouldn't you say? Radical experiments demand radical gains. Surely there is room for an order of magnitude if one is willing to sacrifice general-purpose computing.

<comment><USER7> Order of magnitude performance improvement isn't going to be possible. That basically requires that over 90% of your cycles are currently being wasted by the OS somehow. Maybe this project could get 20% improvement.

<comment><USER8> > _Order of magnitude performance improvement isn't going to be possible._

I think the term 'order of magnitude' has started taking on a connotation of essentially meaning 'a lot'. It's a fair observation, but I hear it bandied about so often that I rarely actually think the parties are in fact using it literally.

<comment><USER7> In this case I don't even think 2x is possible.

<comment><USER9> It depends on how efficient/inefficient the OS's network stack and data transfer to user space is. For managed runtimes in a VM taking advantage of zero copy APIs is a challenge. I don't think 'order of magnitude' is possible but clearly there are a lot of cases where if implemented correctly this idea could dramatically improve performance.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> As far as I can tell, it's a vague concept, and two "authors" who haven't authored anything asking people to help without really explaining any of the goals? Help with what, exactly?

I fully support making more languages embeddable, but this project doesn't seem to be real. I hope there's more to it than what's listed on their site right now!

</comment><comment><USER11> Wouldn't it be more feasible to make the Erlang VM run on Baremetal OS[1], and contribute to it? Thousands of hours will be spent on kernel development and hardware issues for what is mostly duplicated effort.

[1] <http://www.returninfinity.com/baremetal.html>

<comment><USER12> Porting the erlangvm to bmos is what I am currently working on - <USER2> optimisations or compiling erlang to native code will come later.

Cheers,

Darren

</comment></comment><comment><USER12> Running erlang on bare metal has been a side project of my thesis for a while. I love erlang, and I also love getting close to the hardware, which is perhaps why the Ian Seyler's ReturnInfinity Baremetal-OS has drawn my attention and efforts over the past 8 months or so.

Over this time, my colleague Andrew has been tinkering also, and we seem to have a fair degree of overlap in our end goals, hence kERLnel came about.

It is great to see a lot of excellent discussion, both positive _and_ negative. I think all open discussion is useful, even negative comments have a positive affect in their own way. Although I admit I am surprised that kERLnel was even mentioned here, particularly, as we haven't actually dropped any code publicly yet ;-)

There are other exokernel projects out there that may also be suitable also. In fact, not just exokernels, but also a number of {nano|pico|micro} kernels too, however, the idea of hand coded assembler kind of grabbed me completely for some reason.

For me, the project is not about whether X or faster than Y, or anything like that. It is about what I like doing myself and what I find interesting. I think its great for some many people to comment and have different views, particularly different views to myself - this makes the world a better place!

Cheers,

Darren

</comment><comment><USER13> I prefer language agnosticism. Work being done by Nix-OS, a fork of Plan 9, is moving into similar spaces by merely offering you ways of getting direct access to CPU cores for HPC loads: <http://code.google.com/p/nix-os/>

It also has the benefit of having actually existing code right now.

<comment><USER4> That repo is extremely out of date. The lsub.org guys (<http://lsub.org/ls/nix.html>) decided they'd prefer to roll their own "code review" system, and the nix-os repo was essentially abandoned. Apparently they've recently decided to stop using their own code review thing, and just make changes directly in their local tree while taking emailed diffs from everyone else, so there's that.

Edit: oh, and Erik Quanstrom has started shipping the Nix kernel with his _own_ set of patches in the 9atom distribution, if you can handle the hour+ download time for his ISO. There are some other nice improvements in 9atom, too.

</comment></comment><comment><USER14> Okay, I understand developers can spend their time doing whatever they want. Nobody can (or even should) tell other people how they're going to spend their spare time.

But... wouldn't the effort be better spent improving the existing interpreter? The vague description makes it sound like they're trying to run Erlang without an OS "getting in the way". Looking at the language shootout benchmarks [1], it seems like there's still a lot of room for improvement before the OS would be slowing them down. Operating system services aren't causing Erlang to take 3-25x as long as the C code.

[1] [http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=hipe&lang2=gcc)

<comment><USER10> We are completely surrounded by embedded devices, and their numbers are growing exponentially. Everything has a computer in it. You might be shocked to know the power that's in some of these devices... your cable box might be a quad-core 1.2GHz ARM.

Currently, your common options for embedded software are:

* bare-metal with C, C++, or ASM

* load a full OS (i.e. Linux) and run an interpreter to get access to higher-level languages

There are a lot of domains where the problem being solved doesn't require particularly high hardware resources, but requires quite advanced software design. Implementing something like a modern Blu-Ray player's UI and high- bandwidth/low-latency AV in C is rough. You spend a LOT up front on software development costs, and pay more in the maintenance phase. Alternatively, you can save on development and maintenance by running an OS and using high-level languages and existing libraries... but then your board price per unit skyrockets because of the extra processing power, RAM, and flash that you need to support the OS and interpreters.

Access to a modern programming language at a "bare-metal" environment is the holy grain for embedded. It would change the world.

Unfortunately, it has always been practically impossible. And likely still is.

<comment><USER15> Other options:

FORTH. Icky, but I thought I'd mention it; very fast bringup time . . . but then it's FORTH.

A commercial RTOS. There are lots of these, some of them are even pretty good.

We went the C-and-ASM route and ported over some USB drivers from another in- house OS. Worked okay. USB is horrible to work with, and that was actually the hardest part to get right on our system.

</comment></comment></comment><comment><USER16> It would be interesting to see benchmarks to indicate if such a project would give a useful gain in performance, compared to say, just running Erlang on its own, via of the many available OS kernels.

</comment><comment><USER17> Related: <http://erlangonxen.org/>

<comment><USER18> I have been following this project, and it makes so much more sense to me.

As another poster mentioned, going all the way down to the bare metal does not make sense to me.

Or maybe I have lived through too many hardware upfrades to not want to worry about whether the _APP_ will run if we upgrade the RAID controller or something.

<comment><USER19> When Darren and I were looking at baremetal OS - we liked it because we could quantify what Xen and other kernels were missing - generic drivers - and we saw we could improve everything by making a system more specialized and what we wanted to use (think about what you actually put a commercial system on, there's not too much choice - especially for HPC). An example of this would be an athlete like a runner, and a shot-putter. Think of their body shapes - <USER3> are very different! Yet we all treat operating systems as if they are the same (for compatibility). Being more specialist is obviously not for everyone! Linux (or any other OS) is...

Regarding compatibility - my personal long term aspiration is to abstract the HW through LLVM which will eventually allow us to target Xen or other exokernel systems or run more close to the metal by running/developing a true erlang kernel through a mixed ERTS/BMOS (Baremetal OS) code-base.

As mentioned in earlier comments, erlang already has a pretty mean scheduler, and memory management system. Personally as an academic exercise - I'd like to see how this operates at a kernel level and in the future, I'll be spending more time on this. All other existing operating systems I personally believe are just getting in the way of best possible performance.

Finally erlangonxen which you mentioned above is not open source. That does not make sense to me, and it does not give me what I want... Doing this is a very selfish exercise, as it's what I want. Hopefully other people will want (and make sense of) this too, but atm I'm not fussed.

Cheers Andrew

</comment></comment></comment><comment><USER20> Would what's proposed be considered an "exokernel"?

EDIT: To add some context, would it be like <http://www.openmirage.org/> ?

<comment><USER7> It has been suggested that running an app directly in a VM with no OS uses the hypervisor like an exokernel.</comment></comment>


Ray Kurzweil does not understand the brain - <AUTHOR> http://scienceblogs.com/pharyngula/2010/08/ray_kurzweil_does_not_understa.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+scienceblogs%2Fpharyngula+%28Pharyngula%29&utm_content=Google+Feedfetcher <comment><USER2> I personally find Searl's (and other "neural correlates of consciousness" people, such as Koch) arguments more generic and deep than all this simulation-emulation-dna-blah-blah talk. It is perfectly possible that our brain is the minimal thing that capable of self-awareness and, that is, irreducibly caused by physical nature of brain and our universe.

At least, I am sure, emulation of chemical processes is not a way to recreate mind.</comment>


German student in India asked to leave for protesting controversial bill - <AUTHOR> https://indianexpress.com/article/india/citizenship-law-protests-india-german-student-iit-madras-6181941/lite/ <comment><USER2> Governments in almost all liberal democracies (and all other forms of governments for that matter) reserve the right to deport foreigners without cause or due process.

In fact many foreigners have been deported or denied entry without cause (no protesting necessary).

This practice predates W Bush era in the US. Anecdotally it has become more common since W Bush onwards. Hard stats are hard to come by as it is not publicly available data in the US at least.

This is an example of even American citizens being deported in the 1950s under President Eisenhower:

" The short-lived operation used military-style tactics to remove Mexican immigrants—some of them American citizens—from the United States."

[https://en.wikipedia.org/wiki/Operation_Wetback](https://en.wikipedia.org/wiki/Operation_Wetback)

A comedy on US citizen being deported in the 1980s:

[https://en.wikipedia.org/wiki/Born_in_East_L.A._(film)](https://en.wikipedia.org/wiki/Born_in_East_L.A._\(film\))

<comment><USER3> I see. Have you heard of Gandhi? Any idea what he did in South Africa?

</comment></comment><comment><USER4> participation in political events by foreigners is strictly prohibited by law because that is tantamount to interfering in the political process in india. so it is not incorrect that the student was asked to go.</comment>


[YouTube] the IBM 1401 compiles and runs FORTRAN II - <AUTHOR> https://www.youtube.com/watch?v=uFQ3sajIdaM <comment><USER2> as a child of the 90's and a computer engineering student, CuriousMarc's channel has been actually really influential in helping me to better understand how "using a computer" has evolved since the 70's and 80's. It's one thing seeing a slide mention IBM mainframes in passing in a class, another to see someone actually using it. Really love his content.

<comment><AUTHOR> I totally agree (being a child of the 80s). His blog is also a must-have bookmark. :-)</comment></comment>


The Rise and Fall of the Full Stack Developer - <AUTHOR> http://techcrunch.com/2014/11/08/the-rise-and-fall-of-the-full-stack-developer

<comment><USER2> Posted yesterday:

[https://news.ycombinator.com/item?id=8577821](https://news.ycombinator.com/item?id=8577821)</comment>


Graviton Database: ZFS for key-value stores - <AUTHOR> https://github.com/deroproject/graviton <comment><USER3> >Graviton is currently alpha software.

More like the "BTRFS for key-value stores" ;)

Kidding aside, I dislike when new unproven software claims the name of industry standards like this. When I saw the headline, I was hoping this somehow actually leveraged ZFS's storage layer, but actually it is just a new database that thinks Copy-on-Write is cool.

<comment><USER4> Title is very click baity, this is just another kv store, completely unrelated to ZFS.

<comment><USER5> Even their README is click baity then. I quickly glanced at their repo and thought it somehow is related to ZFS, before reading comments here.

</comment></comment></comment><comment><USER6> Nice!

I implemented pretty much the same trade off set in an authenticated storage system.

single writer, radix merkle tree, persistent storage, hashed keys, proofs.

I guess it is a local maxima within that trade off space.

I like how the time travelling/history is always touted as a feature (which it is), but it really just means the garbage collector/pruning part of the transaction engine is missing. Postgres and other mvcc systems could all be doing this, but they don't. The hard part of the feature is being able to turn it off.

I'll probably have a look around later, the diffing looks interesting, not sure yet if it's done using the merkle tree (likely) or some commit walking algorithm.

<comment><USER7> > I like how the time travelling/history is always touted as a feature (which > it is), but it really just means the garbage collector/pruning part of the > transaction engine is missing. Postgres and other mvcc systems could all be > doing this, but they don't.

Postgres actually did tout it as a feature in "THE IMPLEMENTATION OF POSTGRES" by Michael Stonebraker, Lawrence A. Rowe and Michael Hirohama[1] search for "time travel" in the PDF. I added the relevant quotes below for easier access ;)

This was back when PostgreSQL had the postquel language (before SQL was added) there was special syntax to access data at specific points in time:

> The second benefit of a no-overwrite storage manager is the possibility of > time travel. As noted earlier, a user can ask a historical query and > POSTGRES will automatically return information from the record valid at the > correct time.

Quoting the paper again:

> For example to find the salary of Sam at time T one would query:

        retrieve (EMP.salary)
        using EMP [T]
        where EMP.name = "Sam"

> POSTGRES will automatically find the version of Sam's record valid at the > correct time and get the appropriate salary.

[1] - [https://dsf.berkeley.edu/papers/ERL-M90-34.pdf](https://dsf.berkeley.edu/papers/ERL-M90-34.pdf)

<comment><USER8> Is this still possible with Postgres?

<comment><USER7> Yes and no or to be precise - to a certain degree but not through an exposed language feature.

PostgreSQL still does copy-on-write so the old versions of the row exist and are present in storage. However now there is an autovacuum process going over the records regularly marking those no longer seen by any transactions as re- usable so eventually the old records would get overwritten.

You can get at the older versions of the rows directly on disk or perhaps it would be possible to get the db to return such older versions of the rows. It seems that by default even trying to get at them with `ctid` is not possible so that may require hacking PostgreSQL itself or using some extension which seem to actually exist[1].

[1] - [https://github.com/omniti- labs/pgtreats/tree/master/contrib/...](https://github.com/omniti- labs/pgtreats/tree/master/contrib/pg_dirtyread)

</comment></comment></comment></comment><comment><USER9> Does anyone know of an embedded key-value store that _does_ do versioning/snapshots, but _doesn't_ bother with cryptographic integrity (and so gets better OLAP performance than a Merkle-tree-based implementation)?

My use-case is a system that serves as an OLAP data warehouse of representations of how another system's state looked at various points in history. You'd open a handle against the store, passing in a snapshot version; and then do OLAP queries against that snapshot.

Things that make this a hard problem: The dataset is too large to just store the versions as independent copies; so it really needs _some_ level of data- sharing between the snapshots. But it also needs to be fast for reads, especially whole-bucket reads—it's an _OLAP_ data warehouse. Merkle-tree-based designs really suck for doing indexed table scans.

But, things that can be traded off: there'd only need to be one (trusted) writer, who would just be batch-inserting new snapshots generated by reducing over a CQRS/ES event stream. It'd be that (out-of-band) event stream that'd be the canonical, integrity-verified, etc. representation for all this data. These CQRS state-aggregate snapshots would just be a cache. If the whole thing got corrupted, I could just throw it all away and regenerate it from the CQRS/ES event stream; or, hopefully, "rewind" the database back to the last- known-good commit (i.e. purge all snapshots above that one) and then regenerate only the rest from the event stream.

I'm not personally aware of anything that targets exactly this use case. I'm working on something for it myself right now.

Two avenues I'm looking into:

• something that acts like a hybrid between LMDB and btrfs (i.e. a B-tree with copy-on-write ref-counted pages shared between snapshots, where those snapshots appear as B-tree nodes themselves)

• "keyframe" snapshots as regular independent B-trees, maybe relying on L2ARC- like block-level dedup between them; "interstitial" snapshots as on-disk HAMT 'overlays' of the last keyframe B-tree, that share nodes with other on-disk HAMTs, but only within their "generation" (i.e. up to the next keyframe), such that they can all be rewritten/compacted/finalized once the next keyframe arrives, or maybe even converted into "B-frames" that have forward-references to data embedded in the next keyframe.

<comment><USER10> You need something like HBase, but embedded. MVCC would give you the snapshot isolation (perhaps there's something with less guarantees?) and you'd need key lexicographic ordering to do efficient scanning. You'd only need the memory layout (e.g. LSM) if you'd keep a write-ahead-log from which to recover.

LevelDB / RocksDB (and related) may be close, but not sure about MVCC aspects (see [https://www.cockroachlabs.com/blog/cockroachdb-on- rocksd/](https://www.cockroachlabs.com/blog/cockroachdb-on-rocksd/))

<comment><USER9> You misinterpreted, I think. The point isn't "snapshot isolation" in the MVCC sense (working with multiple snapshots-in-progress); it's the ability to, in est, work with the database the way git works with commits: opening a transaction "on top of" a base commit, then "committing" that transaction to create a new commit object, with its own explicit ref, where you can later "check out" an arbitrary ref.

Except, unlike git, this database wouldn't need to be able to create new commits off of anywhere but the HEAD; and also wouldn't need to be able to have more than one in-progress write transaction open at a time. No need for MVCC at all; and no need for a DAG. The "refs" would always just be a dense linear sequence.

Also, unlike git (or a cryptographically-verified / append-only store), there's no need to keep around "deleted" snapshots. It would actually be a huge benefit to be able to purge arbitrary snapshots from the database, without needing to do a mark-and-sweep liveness pass to write out a new copy of the database store.

The key constraint that differentiates this from e.g. a Kafka Streams-based CQRS/ES aggregate, is that you should be able to reopen and work with any historical database version _instantly_ , with equal-amortized-cost lookups from any version, without needing to first do O(N) work to "replay" from the beginning of time to the snapshot, or to "rewind" from the HEAD to the snapshot. This system would need all snapshots to be equally "hot" / "online" for query access, not just the newest one.

In other words, such a database should work just like filesystem snapshots do in a copy-on-write filesystem.

<comment><USER11> It seems like coupling a database checkpoint process with file system's snapshot process should be theoretically possible: 1) Database informed snapshot needed 2) Database finalizes any in progress writes and starts logging new writes to another file 3) Take file system snapshot 4) Inform database snapshot is fine

Between #3 and the file system snapshot, you should have a perfect and quick representation of the database at that point in time (when the database was informed it should stop logging).

<comment><USER9> File system snapshots are a system that have the analogous desired properties _for files_ ; but filesystem snapshots are actually quite heavyweight, because they deal with dirents, inodes, extents, etc. CoW filesystem snapshots are designed for ops-task-granularity usage, e.g. daily backups; not for per- transaction historical archiving. CoW filesystems tend to fall over once you get to 100K snapshots. (I tested!) A database that took a snapshot after every CQRS/ES transaction, could be expected to potentially have _billions_ of snapshots.

A system that did its snapshots "inline" to itself, by e.g. managing a pool of pages with a free-list the way LMDB does — but where Txs ultimately add a new version _to_ the root bucket as a snapshot, rather than replacing the root bucket page with themselves — would get a lot closer to allowing one to have at least tens-of-millions of snapshots online. At that point, to achieve a billion snapshots online, you "only" need to shard your timeline across a cluster of 100 nodes.

This is precisely one of the experiments I'm trying. :)

</comment></comment></comment></comment></comment><comment><USER12> I love the idea but I think you (author) need a lot of time/support polishing this. You need a team probably.

Also,

>Superfast proof generation time of around 1000 proofs per second per core.

Does this limit in _any_ way things like read/write perfomance or usability in general?

<comment><USER13> > You need a team probably

The cardinal rule of database development:

[http://www.dbms2.com/2013/03/18/dbms-development- marklogic-h...](http://www.dbms2.com/2013/03/18/dbms-development-marklogic- hadoop/)

<comment><USER12> Yup, I do not mean to discourage the authors.

I truly like the project and I have a few things in mind that could make use of it already. (Heck, one of them is pretty much Graviton + a front end).

But I cannot just jump into it as there's some real money involved and no one wants to _experiment_ with that.

I see a bright future for Graviton, once it becomes tested and stable in production environments.

<comment><USER14> I'm sure the devs would be interested in hearing about your use cases, should you open an issue on the repo, or got in touch via [https://dero.io/#contacts- section](https://dero.io/#contacts-section)

(I'm not on the team, just interested in the project.)

</comment></comment></comment></comment><comment><USER15> What is the use case? Why is it important that "All keys, values are backed by blake 256 bit checksum"?

<comment><USER16> ZFS stores the checksums of files to prevent bit rotting. Since they are comparing their database to ZFS, I guess it stores the checksums for the same reason. If bit rotting occurs, you don't need to discard the entire database, just the affected entry. If the entry was already there for some time, you might even be able to restore it from a backup.

<comment><USER17> Isn't a 256-bit Blake hash a little OTT, versus a simple CRC, or even a faster, smaller hash like MurmurHash or Jenkins-one-at-a-time?

<comment><USER18> It's a cryptographic hash, so it will detect tampering with the data, which a simple CRC, MurmerHash or Jenkins would not.

<comment><USER17> Still, I'd like an option to use a faster, more efficient CRC or hash - <USER2> rot is usually the main threat, rather than tampering. Not to mention that if a user can tamper with the data they can probably just create a new hash at the same time.

Using a cryptographic hash as a souped-up CRC seems rather odd, given how many more CPU cycles and RAM it will use, but I don't know the reasoning behind the decision; there must be one.

<comment><USER18> > if an attacker can tamper with the data they can probably just create a new > hash at the same time

That's true for ordinary databases, but this was developed for a blockchain and uses a Merkle hash tree.

An attacker can only tamper with the data and create a new hash for a data item by also creating a new hash for every node up to the root of the tree. In a blockchain context, even that isn't enough, they'd have to modify the blockchain nodes as well, as I presume they periodically record tree root hashes.

The hash tree gives it some other interesting features too. O(n) diff time, where n is the number of changes output in the diff, is probably due to having a hash tree.

The fast diff would also work with a non-cryptographic hash, but it would be considered not quite reliable enough against occasional, random errors. With a cryptographic hash, for non-security purposes we treat the values as reliably unique for each input. For example, see Git which depends on this property.

</comment></comment></comment></comment></comment></comment><comment><USER19> You can run a Graviton database. You can also run a database on a Graviton:

[https://aws.amazon.com/about-aws/whats- new/2020/07/announcin...](https://aws.amazon.com/about-aws/whats- new/2020/07/announcing-preview-for-amazon-rds-m6g-and-r6g-instance-types/)

For best results, run Graviton on a Graviton:

[https://aws.amazon.com/ec2/graviton/](https://aws.amazon.com/ec2/graviton/)

<comment><USER20> Naming things is difficult.

<comment><USER21> Not according to git!

We can just call this: ad58cd9088995cfb528187b11c275dad60ce2ec5

And the chip: 59b54f61dd17c27744e884542e35b34172e2cc79

So easy!

</comment></comment></comment><comment><USER22> This is definitely something to look into. so far dero looks like a pretty solid project with out of the box thinking.

</comment><comment><USER23> If latency and performance is an issue there are also solutions like RocksDB or LevelDB

<comment><USER14> There's a brief comparison with RocksDB and LevelDB in the README file, which concludes: "If you require a high random write throughput or you need to use spinning disks then LevelDB could be a good choice unless there are requirements of versioning, authenticated proofs or other features of Graviton database."

<comment><USER23> This was a reply to another comment in the thread that suggested a user use sqlite. I commented using the Octal ios app. Not sure why it didn't post it correctly....

</comment></comment></comment><comment><USER24> Comparison to Badger? Badger is also go-native and, for me, has been exceptional at scale and for read-heavy workloads on SSD.

Ref: [https://github.com/dgraph-io/badger](https://github.com/dgraph- io/badger)

<comment><USER14> I think the key differentiating feature of Graviton is the tree of authenticated proofs of data consistency. (AFAICT this is particularly important for scalably updating and verifying a large blockchain history.)

<comment><USER24> Ah, figured as much but am not as familiar with that use case. Thanks!

</comment></comment></comment><comment><USER25> Someone paste timing results of diffing for very large data sets.

</comment><comment><USER26> What I'd really like is a multiprocess safe embeddable database written in pure Go. So a database which is safe to read and write from separate processes.

Unfortunately I don't think this one is multiprocess safe.

<comment><USER27> I too feel the "pure Go" pull, but is your use case so precarious or latency- sensitive that you can't simply use SQLite? That's what I do in these situations.

</comment></comment><comment><USER28> ... doesn't cassandra do a lot of this?

<comment><USER24> Cassandra is not, traditionally/practically, an embedded db.</comment></comment>


HttpStat: It's like curl -v, with colours - <AUTHOR> https://github.com/davecheney/httpstat <comment><USER2> > _httpstat.py is a wrapper around curl(1), which is all fine and good, but > what if you don 't have curl(1) or python(1) installed?_

So, the point of this is if you don't have either curl or python, but you do have golang. I can't imagine when that would happen. Is it intended for use inside a container?

<comment><USER3> Golang compiler produces static binary files, so you don't need install anything. Just run the binary.

<comment><USER4> But this seems like a developer tool -- what developer doesn't have Python and Curl installed...

<comment><USER5> People on Windows

<comment><USER6> If you develop web apps on windows you'll have Pyton installed.

Also windows has power shell which has its own curl equivalent.

<comment><USER5> the curl you get on powershell is absolutely not the same. The output of curl -v is totally different.

And no, even if you develop web apps you don't necessarily have Python installed. If I wrote node, or C#, or Go, or PHP exclusively, why would I bother with Python ? Sure there are some useful tools in Python, but it's absolutely not a given that you'll have it. Unlike on Linux, where Python is installed by default everywhere and you can basically assume Python is available.

</comment></comment></comment></comment></comment></comment><comment><USER7> Looks pretty shoddy from an IPv4/IPv6 point of view. It uses fmt.Sprintf("%s:%s") instead of net.JoinHostPort, and net.ResolveTCPAddr returns a single IP address instead of a properly-ordered list.

So it will probably fail to connect to an IPv6 literal, or to a dualstack hostname from an IPv6-only client.

</comment><comment><USER8> Please don't use colored output if you didn't first check the background color of the terminal. If you can't check the background color of the terminal, then don't use colored output.

<comment><USER9> Did you checked the code? Because it does exactly what you describe already.

</comment></comment><comment><USER10> Thanks for posting this; I live in macOS Terminal.app, which pretends to be an xterm-256colors, and also displays lots of Unicode characters ok.

Amazed that we don't have better text-based UI, given these common capabilities in 2016.

</comment><comment><USER11> Colored output reminds me of httpie: [https://httpie.org/](https://httpie.org/)

The timings are a nice addition, although I am not sure if there is much use for it.

<comment><USER5> Uh ? the timings are the only thing httpstat does; it's not a client like httpie.

<comment><USER11> Sorry if I misunderstood the purpose. The title of this submission made it sound like this is supposed to be a replacement for `curl -v`.

</comment></comment></comment><comment><USER12> Load testing tools such as Apache Bench or JMeter might be good at measuring performance. Personally I think a single sample might not be good enough.

Otherwise you can just grab data from various requests and feed them to R.

<comment><USER13> This isn't about load testing though. This is about getting some more useful information out of doing a request from a CLI, which can be a very handy way to see if there's an indication of a problem with an endpoint or a specific host.

It can be done with curl but then you also have to write a template for the output and pass it in to curl with -w to get things like timings.

</comment></comment><comment><USER14> Where's the JavaScript version? ;)

<comment><USER15> I'm waiting for a LOLCODE [0] version.

[0] [http://lolcode.org/](http://lolcode.org/)

</comment></comment><comment><USER16> Looks like a good supplement to httping</comment>


Folding Beijing – 2016 Hugo Best Novelette - <AUTHOR> http://uncannymagazine.com/article/folding-beijing-2/ <comment><USER2> Here's the Chinese if anybody is interested in attempting to read in the original language.

[https://read.douban.com/reader/ebook/20769128/](https://read.douban.com/reader/ebook/20769128/)

<comment><USER3> Thanks! Anyone out there know if there is a way to read this in traditional (as opposed to simplified) Chinese?

<comment><USER4> Try this link:

[http://translate.google.com.hk/translate?hl=en&sl=zh- CN&tl=z...](http://translate.google.com.hk/translate?hl=en&sl=zh-CN&tl=zh- TW&u=http%3A%2F%2Fwww.newsmth.net%2Fbbs0an.php%3Fpath%3D%2Fgroups%2Fliteral.faq%2FSF%2Fyuanchuang%2Fwangyou%2Fown%2Ffangfang727)

<comment><USER2> Be careful with machine translated Simp to Trad. Traditional to Simplified character mapping is 1 to many.

When plugging Simplified into Google Translate, the translation therefore is a many to one and Google frequently doesn't get it right. I'm not sure how Google determines the mapping, perhaps by absolute greatest frequency? Here's an example of what I mean with a commonly used character:

(Simplified) 复 maps to (Traditional) 複, 復, and 覆

</comment></comment></comment></comment><comment><USER5> it's not fiction, but reality

<comment><USER6> A universal rendering of the eternal struggle of human race.

</comment></comment><comment><USER7> \--Spoiler alert---

After reading the first chapter and beginning of the second chapter, to me, it seems not a good piece at all. They had the technology of building a folding city for god sake, yet the protagonist is doing some heavy labor dealing with the city's trash. You would imagine such work would long have been automated. Actually, this always has been a problem when I read sci-fi story, some setting are just fabricated to make the plot more emotional but never really fit the common sense of, at least to me, the development of technology.

I certainly hope this whole Chinese writer winning an award wasn't some political move to attract attention.

<comment><USER8> Oh the irony, you really should have finished reading before commenting, as this is very explicitly addressed in the story. It could be argued that this is exactly what makes it realistic or at least provides verisimilitude.

<comment><USER7> Okay. I just finished reading the whole thing. Still a lot of the things don't add up. A lot of the things don't feel right. I can't put it into exact word. But in the link provided by rabboRubble ([https://read.douban.com/reader/ebook/20769128/](https://read.douban.com/reader/ebook/20769128/)), it seems that most reasonable Chinese sci-fi readers think the story is lame if you read the top review. And that's about how I feel.

\--Spoiler Alert--

The whole story actually doesn't seem to have anything to do with sci-fi at all. The plot is evolving around a man delivering letter? What? Is it in Victorian or is it in the future? All sci-fi elements are just stuffed in there and has no actual meat. I think for a good sci-fi, the author should first think through what technology exists in that world and then develop story that is confined to the setting. Not like this story which sci-fi only served as some convenient facts for author to exploit reader's emotion.

Edit.

And wow... thanks for all the down votes, guys. Hope all you've down voted read the whole folding BJ already.

<comment><USER9> > thanks for all the down votes, guys

This may be why:

First you described a defect in the story. But you claim such defects have "always been a problem" in science fiction. So this story is unsatisfying to you in company with a slew of other works, many of which will have been award winners.

Then you speculated that this particular story might have won an award only because it was Chinese, as if the other finalists are likely to have been better. Yet you've made it clear that you wouldn't expect them to be. So your initial criticism, that the story falls short as so much of science fiction does, gives way to a criticism of this peculiar story--but you have only singled it out for being written by a Chinese author. So, it is ordinarily bad, yes; but it is particularly bad for being Chinese.

I do not think you meant it like that, but that is certainly how you wrote it.

As for the premise of this and similar stories: It is commonly held that technological advancement disproportionately benefits the ruling classes, while the workers are made to grind away as usual, life having been little altered. This line of thought may vary in intensity and nuance with place and regime. "Folding Beijing" and many stories like it draw up a simplified world --all fictive worlds are simplified--in which this tenet rings particularly true. Probably the author intends to play with a view on our world as it is, or that part of it which she is most concerned with. Certainly she wants to lay hold of a reader's emotion, to keep them reading (we do not all share your desires in speculative fiction): who does not care about what their own lot may become, or the lots of their neighbors? We may even feel this way when our lots are presented figuratively, as in a world that looks a little too close to our own for being so different--or a little too different for being so clearly our own. Many of us are weak for this sort of thing. But I think it's disingenuous to claim that such a story _only_ does this. It may not serve the function you want it to; but then, if you're used to that in science fiction, you should be expecting it any time you see the label.

(If you want to know, I personally thought this one dull, but I feel that way about a lot of science fiction, too.)

<comment><USER7> > But you claim such defects have "always been a problem" in science fiction.

I wasn't referring to sci-fi in general. I was talking about my personal experience. I specifically had "when I read sci-fi story" in the original comment.

> So, it is ordinarily bad, yes; but it is particularly bad for being Chinese.

Yes, all politics behind this particular piece winning the award is my speculation, but I wasn't saying that "it is particularly bad for being Chinese". It would be hard for someone who doesn't familiar with Chinese netizen culture to comprehend such speculation. Go through comment section of the link provided by rabboRubble ([https://read.douban.com/reader/ebook/20769128/](https://read.douban.com/reader/ebook/20769128/)). Like PR measures described in "Century of the self", <Folding BJ> is covered a lot in the news and planting fabricated idea among certain groups. Most reasonable Chinese sci-fi readers come to the same speculation as me (top review/most voted) while other lesser minds fail to see it, thus the chaos in comment section mentioned in the above link.</comment></comment></comment></comment></comment>


Tracking Flight Path of US Airways 1549 - <AUTHOR> http://www.nytimes.com/interactive/2009/01/15/nyregion/20090115-plane-crash-970.html

<comment><USER2> A common mistake by small plane pilots is to try and make a U-turn and glide back to the airport. It usually doesn't work since you lose so much altitude during the turns. This pilot seemed to do an amazing job of finding the best glide rate and not turning too much - and then somehow figuring out how to land the plane in the water.

<comment><USER3> And you _really_ lose a lot of altitude in the stall you induce in that turn, or trying to extend a glide by back pressure, engine(s) out.

When in doubt, land straight out.

<comment><USER4> One of the articles I perused mentioned that the pilot was a glider pilot as well. I wonder if he acquired some transferable skills!

<comment><USER5> Ex-glider pilots have been known to do awesome and unorthodox things in order to save a jetliner. This tale of the "Gimli Glider" is another example of grace in an extreme situation.

<http://www.damninteresting.com/?p=744>

</comment></comment></comment></comment><comment><USER6> Pretty cool; but amateurs can do almost as well with Google maps and Google Earth: [http://googlemapsmania.blogspot.com/2009/01/short-flight- of-...](http://googlemapsmania.blogspot.com/2009/01/short-flight-of-1549-on- google-maps.html)

Teterboro must have been really tempting, a successful ditching is anything but a sure thing, if one of the wings had caught the water before the other the plane would have started tumbling at over 100mph.

<comment><USER7> the pilot is said to be an experienced glider pilot, probably helped in this situation

</comment></comment><comment><USER8> Beautiful, but I can't believe they left out how the plane cleared GW bridge by 900 feet!

</comment><comment><USER9> I can't wait until someone gets the black box data and History Channel does an animation of the landing trajectory.

</comment><comment><USER10> Nicely done! Long Live the NYTimes!

<comment><USER11> The NY Times does some very good things, but they also keep publishing Maureen Dowd and William Kristol.

<comment><USER11> I don't mind being down modded, I stand by what I said.

But I am honestly curious who here is a fan of Dowd's and Kristol's writing?

<comment><USER12> not me. They sound like broken record player, repeating the same stuff over and over. And Dowd is a misandrist, but that's ok, as it is trendy nowdays.

</comment></comment></comment></comment><comment><USER13> It looks like the pilot decided to not take the chance to land on the small airport, as if he wanted to avoid the risk to crash into the city.

<comment><USER14> That's a good point. With both engines out to provide reverse thrust and likely little if any emergency landing facilities at Teterboro, he probably made the right choice.

</comment></comment><comment><USER14> This is a great report from NYTimes on the best landing since Air Transat flight 236 in 2001 (<http://en.wikipedia.org/wiki/Air_Transat_Flight_236>).

</comment><comment><USER15> This just proves that AI would not be soon here! The pilot did an amazing job, no AI can't beat theat.</comment>


An Intern's Experience with Rust - <AUTHOR> https://msrc-blog.microsoft.com/2019/10/16/an-interns-experience-with-rust/ <comment><USER2> > First lesson: Rust isn't as hard as I expected

We're going to see a lot more of this. As the language has matured, the Rust folks have paid great attention to easing the learning curve. Even with the borrow checker, it's not that far from Java or a scripting language these days. Most people won't hit lifetimes early on in their use.

<comment><USER3> I don't know. I recently took a Rust course and our day three project was to build a simple multi-threaded webserver. The really easy kind in C where you accept a connection and then spawn a thread to handle the request so the main thread can get back to accepting new connections ASAP.

This turned out to be quite challenging in Rust, even when starting from a working single threaded server. Threading the needle on borrows was quite a challenge.

<comment><USER4> Did you learn C (or any other programming language) by writing a multi- threaded web server in it ?

The Rust book actually ends by showing you how to do that, but... there are many reasons why that's the last chapter in the book. Starting there is definitely not the most efficient way of learning Rust.

<comment><USER5> I did for golang. Assuming you know how to program in general it's a very basic task.

<comment> vertex-four Ehh... it's a basic task _as long as you never touch shared mutable state_. As soon as you have to do that, you need to work out what the abstraction for dealing with shared mutable state in your language of choice is.

<comment><USER5> I mean most languages you don't. You lock do some stuff then unlock. Rust prevents a whole lot of bugs by not making it this simple but that means if you pick anything with threading as a task to jump into the language your going to have a much harder time.

<comment><USER4> Rust `Mutex`es are simpler to use than C++ ones.. so if you just `Mutex` your shared state away, writing an app on top of `actix-web` or `hyper` or `tokio` is dead easy once you learn how to use the framework, particularly if you have already done that before in Go.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Anybody else found the last variation annoying from a C perspective? I find that people coming from a web background don't mind writing complex statements in function parameters (seems like due to writing lambdas/closures and such encourages this kind of programming; maybe it makes sense in a lazy evaluation environment), but people with a C background use the last-but-one variation where you use an intermediate variable to capture a prior result to use as a function parameter. I myself prefer the last-but-one variation and it's a pet- peeve of mine that people write large functions/expressions/statements as function parameters when not needed all in the name of conciseness -- I think it affects readability.

<comment><USER7> Generally, I like to keep the temporaries. Mostly it is a consequence of getting burned and trained by the Visual Studio debugger; trying to put anything too complicated into the watch window or even evaluating it in the immediate window tends to be an exercise in frustration. It's also easier to step into the sub-expression/function call if need be when I do this, which is not always the case if it is a parameter to another function.

<comment><USER8> I feel like there is some law in the universe that says that if I don't use an intermediate variable, then I will for certain need that intermediate variable some time later when I'm debugging.

</comment></comment></comment><comment><USER9> While i appreciate the type safety that Rust may provide (even if it is overblown and only just a little, it can still be useful - e.g. while i prefer C, i do like C++'s "enum class"), my two main issues are that it is only a single implementation (and that implementation looks is too Unix-y with the Windows versions looking bolted at the side) and -especially- _too_ slow.

I get annoyed when my C builds take more than a few seconds and a major reason i avoid C++ for my own stuff (C++'s complexity is another reason) and i hear that Rust has worse compile times than C++. This is enough for me to stay away from it.

But if Rust manages to get an implementation that feels at home at Windows with a full IDE and debugger and also gets around C-like compilation speeds, then i'd like to check it out.

<comment><USER10> On the other hand, I think user time is more valuable than developer time and when building complex/efficient software expecting lightning builds isn't just unwarranted, it's selfish.

<comment><USER9> > I think user time is more valuable than developer time

Developers are users of their development tools.

> when building complex/efficient software expecting lightning builds isn't > just unwarranted, it's selfish.

This is wrong. There is no rule that says that you cannot write fast applications with fast builds. It is just that we got used to C++'s slow build times.

This sort of thinking even falls flat on its face when you consider that C provides similar optimization opportunities as C++ (and in pretty much every modern compiler it uses the same backend and most - if not all - optimizations) while compiles much faster.

But beyond that most of the codebase of a decently sized application does not need more than the most basic of optimizations - it is only a tiny tiny fraction that needs that, yet with modern C/C++ (and most other) compilers, the entire codebase suffers for it (i think only Visual C++ allows you to control optimization settings on a per-function basis, but i haven't encountered any codebase that actually uses this outside of temporarily disabling optimizations for debugging and/or working around bugs).

</comment></comment></comment><comment><USER11> People promoting Rust tend to assume that it's the _concepts_ in Rust that don't exist or aren't explicit in other programming languages that are the hard part. In my opinion, that's not true. It's the _syntax_ used to make those concepts explicit. To use the example from the article: lifetimes are not a hard concept to grasp. Knowing when the Rust compiler will require you to make a lifetime explicitly part of your type, vs. when you can elide it? Hard.

<comment><USER12> > To use the example from the article: lifetimes are not a hard concept to > grasp. Knowing when the Rust compiler will require you to make a lifetime > explicitly part of your type, vs. when you can elide it? Hard.

There are only three (or is it four?) rules about when you can elide. Personally? I never write lifetimes, and then the compiler yells at me, and then I fix it by adding them. It's not something that you need to actively think about. You see

        error[E0106]: missing lifetime specifier
         --> src/lib.rs:2:8
          |
        2 |     x: &i32,
          |        ^ expected lifetime parameter

and you add it in.

<comment><USER13> Lifetimes trip me up in Javascript all the time. I think that I have all my callbacks and/or promises lined up and dealt and my app runs fine. Until it doesn't and I discover that there is some corner case in my 5 nested deep callback hell where I didn't catch some DB timeout. I'm looking forward to that never happening again in Rust.

</comment></comment></comment><comment><USER14> "Rust code is wonderful to write and read"

Writing I'm not sure, reading it's just awful, everytime someone show his project on HN I check github and I'm baffled how the code looks bad as a human reader. (){}<>''-_

<comment><USER15> I feel like, whether with human or computer languages, you can only really say what the experience of reading a language is like once you're fluent in it; and you can only _compare_ the experience of reading a language to another if you're fluent in both of them.

Like, to me, the human language of Vietnamese looks like a mess of accents, and I'm baffled by why they're necessary. But I'm not a fluent speaker of Vietnamese; and I can imagine that, for someone who _is_ fluent in Vietnamese, and another sibling language like Chinese, maybe the extra accents actually compare very well and help readability compared to e.g. the reduced set of accents in Chinese _pinyin_.

Likewise, I would suspect that for someone fluent in both C++ and Rust (i.e. someone who knows how to write code that takes advantage of arcane language features in both), Rust might be more readable than C++ _because_ of some of the initially-offputting syntax, whereas C++ might seem less readable because it eschews extra syntax in favor of using template constructors for everything.

<comment><USER16> This reminds me of my experience with TypeScript. I kept noticing it and feeling a little irritated by its popularity. God it added so much noise to the code. JavaScript was fine for years. I got stuff done. I caught the bugs and debugged them.

Once I finally took the plunge and committed a full project to learning TypeScript, I grokked it. I no-longer saw noise, I saw signal. I saw details about interfaces that I used to have to infer, document, or reverse engineer if I forgot.

<comment><USER17> Incidentally - I have the reverse issue.

I had (still have!) trouble reading JS, because the vast majority of things I've worked on have been in statically typed languages. JS was baffling because I always have to try to infer/reverse engineer things that I can just read off in the languages I'm most familiar with.

The only way I really could handle dynamic stuff was for things like scripts, where I could mostly remember the entire set of types.

I've gotten better with JS after using some TS, but that difficulty still exists. Correspondingly, I'm delighted by Rust - sure, it's a verbose language, but that puts everything I want to know _right there_ for me to read.

</comment></comment></comment></comment><comment><USER18> That is also not how you would write it in idiomatic C++.

The "before" example is C, or bad C++. You are allowed to write bad C++, as you are allowed to write bad Rust. But if you are to compare langues honestly, you should be comparing good code in one language to good code in the other.

The alternative is tendentious but typical, and nothing to be proud of.

<comment><USER7> I wouldn't expect an intern to write idiomatic modern C++. That looked to me to about what I would expect from a university student that had passing familiarity with C++ from their coursework; there is still an unbelievable amount of "C-with-classes" in active use and pedogogy kicking around.

<comment><USER19> Given how we used to teach C++ to university first year students back in 1994 - 2000, it still confuses me that there are so bad teachers keeping "C-with- classes" in active use.

Basically, even without the STL, the students would get our department C++ library with the usual stuff (strings, arrays, vectors, bounds checking enabled), and the teaching would be similar to the way that Kate Gregory preaches how to teach modern C++.

</comment></comment></comment><comment><USER20> Although object lifetime and borrowing is mentioned, he focuses on the pattern expression which he's likely to get in any modern language.

Rust has many great qualities and I've been looking to find a project for it, but it just doesn't seem like the model for long-running processes with immutable data-structures and complex/dynamic/interlinked lifetimes. Seems like dev. effort is better spent on functionality than managing lifetimes, especially given that modern GC is so fast. (And I've seen C++ ports to C# become faster, due to unneeded calling of copy c'tors, and other goodness.)

I can totally see the case for Rust in systems code where lifetime is gated by a system/API call and you want to safely pass buffers around during the duration of the call, for inner-loop gaming, for embedded, etc. But seeing it's en vogue, there are many examples of Rust code where it doesn't seem like the right tool -- but then again, I feel that way about much code written in C++ as well.

<comment><USER21> You don't spend developer time "thinking" about lifetimes as you write Rust, it becomes totally automatic, no more than you spend time "thinking" about functions in C#. The benefits you get far outweigh the negligible overhead, providing things like data race prevention across threads in addition to memory safety with incredibly low overhead. Modern GCs are fast _er_ but they're by no means free, and totally unnecessary if you just give the compiler the information it needs to do its job statically instead of continuing to strap more rockets to the GC rocket-powered horse. It's the _fastest_ horse but it's still a horse, not a car.

<comment><USER19> Try to write a sizeable Gtk-rs application to see how automatically it gets if you don't create your own clone macro to deal with all the Rc<RefCell<>> instances, like the Gtk-rs samples show.

<comment><USER21> I'm not sure a single example of a C wrapper not idiomatically designed is a good example of the potential of a language. It's like pointing to the source for any given STL implementation as quintessentially C++ coding style. RefCells tend to be considered an anti-pattern AFAIK since they leave invariant checking to run-time. It's meant as a hack/patch if you can't actually design it idiomatically for some reason, such as in this case, FFI to a C programming model.

<comment><USER19> I can point to other UI examples, like game engines written in pure Rust, using array indexes with clocks on access to invalidate possible use-after- free accesses with outdated indexes.

</comment></comment></comment></comment></comment><comment><USER22> Rust is pretty neat and I would like to use it more. It seems like it could be the ideal tool for performance-optimized software, like C++ was 15 years ago. Unfortunately, there isn't all that much performance-optimized software that I am writing nowadays.

</comment><comment><USER23> The person writing this seems to be a very clever and capable individual. That being said, I would imagine a company the size of MSFT would have a senior engineer coding "a security critical network processing agent". That sounds like a lot of responsibility for someone inexperienced.

</comment><comment><USER24> the `{y:2, x:1..=4}` syntax is confusing, is it really range checking ?

<comment><USER12> Yes, it says "match if y is two, and x if it's between one and four, inclusive".

<comment><USER24> Weird couldn't find it in the Book.

<comment><USER12> We don't cover this exact combination of features directly in the book; this falls out of composing the "pattern match" feature with the "range" feature.

It's also possible that you're reading a version of the book before the ..= syntax was introduced; it hasn't been there since 1.0.

</comment></comment></comment></comment><comment><USER25> Interesting.

Now if only the images with code actually had the snippets in code form I would be able to share the blog post to other people.</comment>


Mysterious FCC filings hints at new version of Google Glass - <AUTHOR> http://americans.org/2015/07/05/fcc-filing-reveals-google-readying-new-version-of-google-glass/

<comment><USER2> I thought their explorer prototype product was interesting, but the problem persists that many people will not want to interact with people wearing glasses with embedded video cameras. By law in some countries there has to be an some indicator when the camera is capturing data but the visual indicator probably makes some other people more uncomfortable or angry.</comment>