ktamura

As a long-time developer marketing person, I must say Rust is kicking ass, not just as a language but as a community. They are deeply strategic.

1. Clear audience target: They aren't going after C++ gurus or C magicians but people who are new to systems programming. From Klabnik to Katz to literally everyone in the community, they are consistent with this messaging.

2. As part of 1, they have invested a lot in teaching systems programming 101 (heap v. stack, etc.), i.e., stuff that you learn in the first course in systems programming in college, but many self-taught, higher-level programmers might not know. This is a great example of authentic content marketing based on a clear strategy working out.

3. Their community is very inclusive. My experience (as a marketing guy who barely remembers how to code) is that people are very helpful when you ask questions, submit a patch, etc. This has been the case for me not just with Rust itself but a couple of Rust projects that I've interacted with.

Any good alternatives for Sqoop? I feel that an ETL tool just for HDFS is too limiting and leads to further fragmentation on the data pipeline.

Anyone to share their stories living and working in Maine? My background: I have a great job in SF, but SF is such a terrible city to live in. In the 5 to 10 years time frame, I am strongly considering moving away from SF.

>Providing a reliable connection between the Bronx, Queens and Brooklyn by rail will provide more direct trips within and between these boroughs than either the subway or bus networks can do today. Buses make up 43% of transit ridership in these three boroughs, but buses operate at an average speed of 8 mph as they fight the city’s heavy traffic.

It's amazing to see New York City suffer almost half a century after Robert Moses's decline.

One of the worst consequences of Moses's 600 (or was it 700?) miles of highway is how residential areas outside of Manhattan developed: Because he built the city around highways and hence commuting by car, residential areas outside of Manhattan developed into thinly spread suburbs, making it near impossible to create an efficient network of trains. To New York City's credit, they've made a laudable comeback with subways: After all, it's the city you can live without owning cars in the United States. Yet, our generation continues to pay the price of Moses's ego and lack of foresight.

RM is a humbling reminder that getting wrong stuff done so effectively has grave and lasting consequences.

>Moreover, in Plan-9, many of the "good old things" were removed and a lot of incompatibility was introduced in the system with respect to the other Unixes. This prevented many different companies to even start thinking of porting their applications to Plan-9.

This is fundamentally why plan9 didn't take off. It was too different and not better enough.

Platform technology marketing is being on the right side of a nuanced dichotomy:

1. You need to be different enough to be noticed and given attention 2. And better in the eye of the user (which implies familiar)

For example, OSX was a great success among hacker types for this very reason: It was different yet familiar (Most UNIX-y stuff just worked on OSX thanks to its FreeBSD lineage).

Another example is Go: It's different enough from the previous generation of server-side languages to command attention, but its syntax was very much in the C language tradition (And it articulated its "betterness" well, such as performance gain over Python/Ruby and ease of use over C/C++/Java).

Fundamentally, Plan9 was way too different from the incumbent without any clear advantage.

That's one part of the piece that I disagreed with as well. That said, it's true that Apple is not a AI-first/data-first company. As a result, they have less data and data culture inside the company. While these acquisitions may change their culture incrementally, it's unlikely that their company DNA catches up to Google/Facebook's.

Culture is a powerful force in shaping products. For better and worse, Google/Facebook have the "let's use customer data to build products" DNA ingrained into their company DNA. Of course, this has pros and cons. At times, their thirst for customer data can be creepy/controversial while Apple's steadfast support for customer data privacy is assuring.

Ultimately, it comes down to this: How willing are we to exchange our own behavior and demographic data for convenience? If the answer is yes, then the future is as Marco predicts it.

The question Marco was posing is different: What if hardware mattered less to the point that consumers will switch over to different hardware with better/1st class software support. If that happens, the future doesn't look too bright for Apple (or so posits Marco).

Apple might as well continue to be a first-class hardware-first business. However, if their hardware advantage is eclipsed by their data/AI disadvantage, Apple might lose a big chunk of their market share.

>But if Google’s right, there’s no quick fix. It won’t be enough to buy Siri’s creators again or partner with Yelp for another few years. If Apple needs strong AI and big-data services in the next decade to remain competitive, they need to have already been developing that talent and those assets, in-house, extensively, for years.

This is so true. It's not easy to out-accrue data over your competitors, especially if your competitor has multiple services used by millions of people everyday. This has an interesting side effect when it comes to hiring: The companies with "best" data have a better chance of hiring the best data talent because they can provide most challenging problems (for systems and data engineering people) and better equipment (There's no substitute for a vast amount of high-quality data for data scientists). This, in turn, means that best algorithms will come from data-rich companies.

What Marco is hinting at is that smartphones will increasingly become a conduit for data-intensive algorithms. If this is indeed the case, it means that data-rich companies can create deeper engagement and hence acquire more data, and the virtuous (or vicious?) loop will continue.

I personally think SQL v. NoSQL is less useful of the two dichotomies, the other one being OLTP v. OLAP. In the end, SQL is just an API. You can put SQL-like interface on NoSQL as well (like SlamData for MongoDB or Crate for Elasticsearch).

On the other hand, OLTP v. OLAP (transactional v. analytic) is directly tied to use cases and has more profound consequences as far as technical decisions go (data structures, algorithms, etc.)

>I have issues with his "Reasons to use NoSQL"

Looking at the author bio at the bottom, I believe it is "her".

First TensorFlow and now this. Tensor is quickly becoming a mathematical-term-that-sounds-familiar-to-developers-but-most-don't-know-what-it-is-actually.

Another example is topology =)

What's really sad about this is that they had to give up Leaf because the whole thing was VC-backed. Commercial support is a huge part of open source software's viability.

I applaud their decision to pivot and shift their focus elsewhere to win. That said, the irony is too great for me not to mention: open sourcing is now recognized as a hugely democratizing force in the software world to upend commercial giants, yet it's commercial giants that can afford to invest in the long run and support open source projects (so that they can increase the sphere of their influence).

Another piece of "marketing" collateral that can help popularize Emacs is a "tour of Emacs" video. Awhile back, I watched Russ Cox's "Tour of Acme" video and became an Acme convert as a result.

In the end, an editor is a productivity tool, and the best way to evaluate it is seeing it in action as part of a workflow: video is an excellent format to capture and share this with newcomers.

"The company, based in Palo Alto, California, is essentially a hybrid software and consulting firm, placing what it calls “forward deployed engineers” on-site at client offices."

This says everything about Palantir, and depending on your perspective, their valuation is (not) justified.

It's justified if you think of the equation Palantir = McKinsey + IBM. On the other hand, no consulting firm should have 20x revenue multiple.

I see a pattern emerging here: One phase of an enterprise producing training data for another phase of the enterprise to create massive automation.

In this case, it's Lyft and GM joining forces, but this kind of partnership can (and should) happen between a company good at logistics to produce training data quickly and efficiently and a company good at turning that into data products.

Some companies are good at/doing both in-house: Amazon (E-Commerce and IaaS), Google (self-driving cars and search), Facebook (The world's most addictive website) are some of the examples.

If I were a small group of AI powerhouse, I'd definitely consider approach bigger companies with excellent logistics producing rich data.

Toil is very much reminiscent of Luigi. I hope the author(s) will elaborate on this here (or elsewhere): There's very little on both readthedocs as well as their GitHub repohttps://github.com/BD2KGenomics/toil

Really? Do you code for a living? I ask because I am a technical marketer at a startup (i.e., I have to read some code, but mostly my work is done inside Gmail and Google Docs) and could totally work fine on a low-end Chromebook when my Thinkpad was out for a week in repair.

oh yea, I remember your blog. As a matter of fact, it was one of few variable resources to learn about Acme's "API". Thanks for your work =)

Neat idea. I've been using something like this with Acme from plan9port.

Acme's plumber lets the user customize behavior on a piece of text based on its context or a program that takes it as an argument.

A previous discussion about Acme on HN: https://news.ycombinator.com/item?id=4533156

YKK epitomizes why Japan, despite the recent decline, continues to be a major economy: manufacturing giants that continue to serve as the backbone of the global economy.

Another example is FANUC [1], a manufacturing device maker headquartered in Yamanashi, Japan's equivalent of Idaho (i.e., there are people there, and I'm sure it's nice to live, but few travel there for vacation).

There are countless such examples: Minebea [2] https://en.wikipedia.org/wiki/Minebea has 60% market share for miniature bearings (ex: the trackpoint for Thinkpads) and has been more than doubling their revenue YoY.

As long as Japan's high-end manufacturing sector stays healthy, they will be fine for a little while.

[1] FANUC stands for Factory Automation NUmerical Control. You've gotta love Japanese people's creativity when it comes to company names.

[2] Minebea stands for Miniature Bearing. Again, very creative.

Don't forget that Heroku is the original multi-tenant shop. I wouldnt be surprised if a single Kafka instance stores multiple customers's messages and elastically scale as more customers/data is added.

Some of the claims made by the author are just false (or glib theatricity). For example, you can definitely calculate capped running total without vendor-specific grammar.

It beats me as to why HN hasn't implemented duplicate detection.

While I really like K/Q/J/APL (some of this is Stockholm Syndrome: I spent the first 3 years of my career writing K/Q at a trading firm, eventually becoming the human debugger for my team's K/Q "investment". It got so annoying that I worked on a little parser library to help me debug: https://github.com/kiyoto/ungod), they are doomed from a adoption/future viability point of view.

1. Steep learning curve without benefits: APLs like K/Q/J optimize for concision to the point of unreadability. Sure, it might be fun to decipher clever K/Q one-liners, but if you have to do it everyday for work in production, it's just exhausting. This lack of readability has limited adoption and the growth of its user community. For any technology is to have a viable community, it needs to be usable by a critical mass. K/Q in specific but APLs in general never had that, especially with more user-friendly alternatives like R/Matlab for scientific computing.

2. No open source community. There's Kona (https://github.com/kevinlawler/kona) by Kevin Lawler, but again, its community has been small because the underlying language is not design to be usable by enough people.

3. Domain specificity of array languages: These days, array languages are just too limited in its scope. Scientific computing, the bread and butter of any array programming language, has been made possible in other languages (ex: Python), making array languages not powerful nor compelling enough to use because most of its strengths can be found in other languages and its weaknesses are too crippling.

I heard that Arthur Whitney found his successors (a pair of Russian programmers from St. Petersburg, iirc), so K/Q will likely to be around beyond his retirement. That said, I think its user base will continue to shrink for above reasons.

Firefox's problem is not lack of features. It's performance.

To be sure, Firefox isn't the worst by many metrics, but it's no longer the stand-out that it was circa 2005-2008. That's why Firefox users left it for Chrome.

And here we are in 2016, I feel that Firefox has a legitimate chance of fighting back if they get their act together. Chrome has become heavy on resource usage while Safari can be sluggish at times. Microsoft has done a great job with Edge but it's bound to Windows 10. This is the opportunity that Firefox should seize.

Yet, they seem to be permanently confused about what they want to do. Chucking Firefox OS was a brave and laudable choice (I say this as a former user, not just an owner, of Firefox OS). But then they work on this? Seriously? Just keep your heads down and concentrate your resources on making Firefox faster and more efficient. Everything else will come with it.

I think OP means GCP: Google Cloud Platform. There's GCE, Google Compute Engine, as part of GCP. GCE is also different from another GCP product Container Engine.

There's one area where Lyft is ahead of Uber, the whole "we are nicer" thing discounted: investment from an auto company (Lyft took money from GM).

If you take a truly long-term view, the marketplace for on-demand drivers will become obsolete once autonomous driving becomes good enough to be adopted everywhere. At that point, Uber's biggest edge -financing and supply-side field logistics- will erode very quickly against companies that own vehicle production (auto giants) and AI (autonomous driving)

Uber knows this, and that's why they have been investing a lot of money on robotics and AI around their partnership with CMU. However, they still do not get the kind of data Google can get from their Maps and Waze (It's interesting to note that Lyft and Waze partnered) to enable their AI researchers.

Uber is still going to be a very successful company in the next few years: For technical and legal reasons, self-driving, on-demand vehicle services will be at least a decade out. But I'm not as sure about Uber's survival in, say, 20 years.

If you want an SQL like interface for Mixpabel data as well as other data sources, you might find Treasure Data useful. Here is a step by step guide that I wrote: https://blog.treasuredata.com/blog/2015/11/17/mixpanel-expor...

(Disclaimer: I work for Treasure Data. That said, there's also an open source way to do this with Embulk + many common SQL databases. See https://github.com/embulk)

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon.

I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacrificing too much performance. Generics would be nice to have for this core use case for Go, but it's probably not critical.

>To respond to your point about absence of Grok like facility, avoiding the need to unmarshal and remarshal the data while passing through LogZoom was an explicit design requirement. The blogpost refers to our pain with Logstash/Fluentd etc.

I think there are two different (CPU) performance problems conflated into one:

(1) The cost of parsing logs with something like Grok and Regexp

(2) The cost of marshaling and unmarshaling data

While both do cost CPU time, based on my experience having talked to literally hundreds of Fluentd users (I'm a maintainer and was a core support member for awhile), the cost of (1) dwarfs the cost of (2). (2) is pretty cheap if you use efficient serializers like MessagePack. As for (1), both Logstash and Fluentd support an option to perform zero parsing (In Fluentd, it's "format none"). By using these options, you can bring down CPU time significantly.

All of this being said, it looks like LogZoom isn't a true competitor to Fluentd or Logstash or Heka. It made different performance/functionality trade-offs and by doing less, it saves more CPU time: If you forgo the option of parsing logs at source (and in Logstash and Fluentd's defense, they do a whole lot more), you obviously can save resources. On the flip side, you need to post-process your logs to make them useful, and some other servers downstream will pay for CPU (You might not care about this because your logs have been thrown over the fense and now it's data engineers's job =p)