Migrating to GraphQL: A Practical Assessment - <AUTHOR> https://arxiv.org/abs/1906.07535 <comment><USER2> I can see absolutely no positive value whatsoever in GraphQL for internal APIs. You're basically saying 'please, formulate any query you like, and I will waste years of my life trying to optimise that general case'.

Seriously. For internal stuff you want to be _as specific as humanly possible_. You want to optimise the living fuck out of that hot path thousand- times-a-second query, and build an entirely separate service to handle that particular URL if necessary.

For a public API, why would you ever encourage submission of arbitrary queries? They will destroy your database servers.

Note that SQL vs. NoSQL is not even a competition here. An RDBMS can handle _arbitrary_ queries much better than any brute-force map-reduce system, and doesn't require spending thousands of man-hours writing your own query planner. The difference is that it doesn't (always) automatically scale horizontally.

So from where I'm sitting, GraphQL is nothing more than an invitation to maintenance and performance headaches, predicated on the idea that everyone scales infinitely horizontally and can brute-force every query.

Personally I prefer being able to serve a thousand queries a second from a single server managing a 1TB database with a 50GB working set, with a latency under a second even when (looking at the raw query) it 'should' touch more rows than there are atoms in the universe.

[edit] In light of the replies, I should express some surprise that building REST endpoints is expensive. If you can execute at runtime an automatic combination of various other endpoints to produce a result, is it not equally simple to generate the code necessary to do the same? That can at least be examined and maintained more easily than dealing with the massive array of possible varations to known-working queries which comes with modifying the rules driving the GraphQL evaluator...?

<comment><USER3> GraphQL was created at Facebook specifically for internal APIs. The motivator was to avoid having to write a custom endpoint for every single REST query, because otherwise REST is not efficient.

Note that GraphQL does _not_ allow the specification of arbitrary queries - much like REST does not allow access to arbitrary resources - the sever defines what queries are available and the user can choose to request a selection of them, and to pluck data from them (or follow links - simply a JOIN).

In other words, GraphQL lets you combine a subset of pre-defined queries in one go.

<comment><USER2> 'Combine a subset of pre-defined queries': you mean run a bunch of queries and perform the join locally? Like a poorly-designed app server 're-using' several repository methods and doing joins in-memory?

I may be misunderstanding something here, but when 'general' queries are combined externally a lot more work is done than is necessary. Which may be fine for small intermediate sets. But treating it as any kind of general solution is silly.

That said, people do similarly stupid things within individual codebases running in individual services to a single database, so as usual it likely comes down to how the tool is used rather than how it can be abused. Still, spreading these things across services and processes looks like it only makes abuse easier.

<comment><USER4> Not sure I understand why in-memory joins are wrong by default, especially in a large system with more than one data store.

Let's say you call UserService::batchGetUsers(userIds) to get a list of users from a service backed by a MySQL DB, call WidgetService::widgetsForUser(userId) to get a list of a user's widgets from a separate service backed by a Redis cache and another MySQL DB, and return them. What's the problem here? Lack of transactions? Unnecessary fields sent down the wire? Something else?

<comment><USER5> There is no problem, the same way GraphQL does not automatically allow arbitrary queries.

The parent author holds some very stubborn beliefs about how systems are built (his/her way is the correct way!), which is great for discussion, but probably not the best example on how to actually build big systems.

</comment></comment></comment></comment></comment><comment><USER6> I don't think there's any surprise that GraphQL reduces the size of the responses compared to typical REST (excluding things like JSON:API). If that's the measurement that's most important, then it seems GraphQL is the obvious choice.

For myself, the 'practicality' of GraphQL would be more on complexity of the implementation, training of engineers, potential re-implementation of client logic, ease and depth of debugging, performance, etc. It seems these days that the size of the response is not typically a limiting factor in most applications I've interfaced with (though maybe I've never been exposed to that world before).

Can anyone speak to how a migration from REST to a GraphQL went? My biggest concern is around the complexity of the thing. It just seems so much more complex than REST, but maybe I haven't spent enough time with it.

<comment><USER7> We migrated from RESTful HTTP to GraphQL and then back to RESTful HTTP. GraphQL is cool, but actually maintaining it is a nightmare and I think it would be rare for the end product to turn out better. Here's a few of the cons for us:

\- GraphQL parsing and interpretation is considerably slower than RESTful JSON. I'm talking an order of magnitude difference in .NET Core.

\- The required POSTs cannot easily be (if at all?) cached by caching services such as Cloudflare

\- It's more work to have to define what data you want than to just spit out the data that's available. Having to continually update your client side queries in order to fetch all the available data is tedious as hell. The whole over/underfetching argument is not worth the incurred performance hit nor the bandwidth improvements.

\- GraphQL promotes laziness about documentation because it's "self- documenting" \-- turns out most API users still struggle to understand how it works and need better API guides anyway, so the reflection is largely useless (it's about as good as those auto-generated Java docs you find on Oracle's website.)

\- Users get RESTful. They know it, it's not a toy, and it just works. I'll repeat this again because Silicon Valley doesn't seem to get it: GraphQL is not user friendly.

<comment><USER8> > The required POSTs cannot be easily (if at all?) cached

GraphQL allows queries to be performed with GET:

      http://example.com/graphql?query=query{user{id}}

You want to use POST for mutations, but read queries can be run through GET and cached just like REST. There's literally no difference -- it's HTTP, after all.

<comment><USER7> There is a difference. When "everybody" has a unique query, there's no cache.

<comment><USER9> In practice, doesn't everyone run the same query in Production? If variables are being used, they're the same degrees of freedom that rest had anyway, right?

</comment></comment></comment></comment></comment><comment><USER10> If anyone was around when SOAP was being pushed on the dev community as the new way of structuring Web-like APIs, you may agree with me that SOAP was a good idea, but too complex and slow to implement - with questionable immediate / long term benefits. I don't think SOAP is in real prod systems much anymore. GraphQL, to me, inherits some issues of SOAP: complexity, non-mainstream terminology ... So, if I develop just fine with REST, moving to GraphQL is an added pain for me, and the dev community picks simple and straight-forward stuff over complex - as the SOAP's history teaches us

<comment><USER11> SOAP, itself, wasn't too bad. What was bad was all the enterprisey architecture-astronaut cruft that people insisted on burying it under. (Kind of the same thing that happened with Java EE.)

Beware if your favorite technology catches on in the BigCo world, because when those people fall in love with something they end up hugging it so hard they strangle it.

<comment><USER12> That stuff buried it, but it was a dead horse already - object RPC is the wrong mindset for internet RPC, doesn't treat latency (and thus async calls) and errors as first-class concerns.

</comment></comment></comment><comment><USER13> The author of the paper forgets, that asking the API to only return specific attributes of an object(tree) instead all of them, can also be achieved with Rest.

e.g. /api/v1/getUser?id=1234&return=name,zipCode,workplace.address,workplace.zipCode

Not sure if that has changed in the meanwhile, but when I tried GraphQL for the first time it was obvious for me, that every service call has to be implemented by hand. Depending on what functionality is required, implementations of service calls can get quite complicated.

As someone coming from Java where we have ORM frameworks and tools like Spring, I was surprised that Facebook didn't come up with something better.

But hey it's Facebook. A company where the CEO thinks it's cool maintaining a huge codebase mostly written in PHP and C(++).

<comment><USER8> You'll end up inventing your own ad-hoc GraphQL that way. For example, GraphQL supports this, trivially:

      query User {
        user(id: "123") {
          id
          name
          topPosts(limit: 10) { id, title }
          drafts: comments(published: false) { id, body }
          friends {
            id
            photo(size: "100x100") { url, width, height }
          }
          newestPosts(since: "3days", categories: ["news", "chat"]) {
            id, title
            forum { id, name }
            creator { id, photo(size: "100x100") { url, width, height } }
          }
        }
        latestNews(limit: 10) { title, url }
      }

All one query. Selecting a subset of attributes is a small part of GraphQL. (gRPC also allows you filter fields, but doesn't have structured querying.)

GraphQL is a protocol and a schema language, not an ORM. It's a way to provide a common interface on top of any implementation. For example, in the above query, users could be in the backend's own database, whereas "friends" could be something stored in a completely different backend. The GraphQL server could trivially act as a façade that federated/aggregated the results of both.

I would argue that GraphQL fulfills the objectives (or at least desired features) of REST much better than what has been delivered thus far. For example, REST's hypermedia aspect ("HATEOAS") has not been widely adopted — because discoverability is poor and there's no standard protocol for introspecting a schema. But look around and you can easily find a dozen different GraphQL clients (my personal favourite being Prisma's GraphQL Playground [1]) that can be pointed at any GraphQL-compliant server to run queries and browse the schema.

Those that criticize GraphQL generally don't seem to realize how simple it is, and how close it's still to the REST style of consuming and producing JSON.

[1] [https://github.com/prisma/graphql- playground](https://github.com/prisma/graphql-playground)

<comment><USER14> I'd argue that the growing popularity of Swagger/OpenAPI is close enough to HATEOAS as we want to get.

<comment><USER15> Swagger/OpenAPI is very fragmented, it builds on JSON Schemas by adding some properties and removing others, then on top of that the AWS API Gateway again removes some options and adds others. Its a total mess trying to navigate which features I can and can not use.

</comment></comment></comment></comment><comment><USER16> For others, esp. on mobile [https://www.arxiv- vanity.com/papers/1906.07535/](https://www.arxiv- vanity.com/papers/1906.07535/)

</comment><comment><USER17> If I write an API that exposes the resources A,B and C. Now I use graphql to access a subset of all of those resources, doesn't this just mean that I have written the wrong API? That I would ditch A,B and C and write a resource D which just did that I wanted?

<comment><USER18> You can make an API that exposes exactly what a client needs, but then the server/client are tightly coupled (and it's not RESTful). What happens when you have multiple clients, and long lived releases with differing requirements.

<comment><USER17> But that's not what I mean. I mean that your original resources are not the the actual ones you should expose. Hence you have designed your API wrong. And I don't agree that a _resource_ becomes more tightly coupled if you write it right. It is a resource after all.

<comment><USER19> Just because requirements change, doesn't automatically imply the original design was bad.

<comment><USER17> But that's the thing. Should you invest in an obsolete API or just change it? If you don't, you have both an obsolete API and a more complex solution instead of just changing your API. And if you don't change your API to adapt to the newer requirements, but use Graphql to "bridge" that problem, you now have a client that's heavily invested in your old obsolete API with a technology glued to it. To me, that sounds like a bad idea.

<comment><USER19> In the case of GraphQL and in the most prolific examples (Netflix and Facebook), you're not considering that the time to setup a GQL interface is less in aggregate than modifying many, many APIs for data that is distributed across varying data stores, often column/kv structures. These are also organizations doing more than just public facing pieces. For example, Netflix has to deal with art, media, and licensing that will vary by location, language and even distribution models under different contract terms for a different region. That's only one aspect of how things work.

In the end, an API written for one department may not match the needs of another, and another still may need additional related aggregate data. In the end, would you rather define your data sources once, or communicate API needs across several departments and maintain 3x or more the surface area to support them?

edit: I'm not saying GraphQL is appropriate for _all_ scenarios... but I'm saying it is definitely better for many.

<comment><USER17> But graphql cannot do more than the API already does? It's constrained to the capabilities of the API. Such as if there's no way of updating a field, graphql won't do that either? So it can only make over-fetching more efficient? And by what you are saying, it's more complicated to create a new resource than incorporating several endpoints with graphql, I find it hard to believe.

<comment><USER19> Imagine the scenario, where you're a developer on one team and need to consume data owned/orchestrated by another team. _YOU_ don't have access to their data source... you either get a custom API that will be updated when they're able to, their priorities are different from yours and under a different internal organization. With GQL, as long as the source data is defined, you get as much or as little as your queries define. With API only, you're stuck explaining to your boss why you have to wait for another team in another org to let you get to it, because they have other priorities.

<comment><USER17> But Graphql doesn't enable more functionality than the API already gives you. You don't get more access to data just because you use graphql? And a team that gives direct access to their data is in very much deep trouble already. I really don't get what you are getting with this.

<comment><USER20> > You don't get more access to data just because you use graphql?

The data you expose via apis is often one "view" of the actual rich data store you own. If a dependent team wants more data than your rest api provides, it is blocked on you adding that data to your api.

If you instead provide a way to query your data store, the dependent team isn't blocked on you.

<comment><USER17> >If you instead provide a way to query your data store, the dependent team isn't blocked on you.

This means that you bypass the API and give direct access to the data? Why have an API at all then?

Don't you think that this mean you tightly couple the data storage with the client?

<comment><USER20> > This means that you bypass the API and give direct access to the data? Why > have an API at all then?

False dichotomy.

You're not bypassing the api. You're exposing a richer api. Use the right terms.

The purpose of exposing apis is not to limit the attributes of exposable data. Eg your definition of an object that the rest api represents May evolve over time while the api does not since they may not be in sync in the code. With graphql this is handled automatically.

Of course it's tightly coupling data storage, that is the point! The problem with using rest apis when doing this is that you can't then change your api without breaking dependencies. Graphql recognizes that in a rapidly evolving data model, trying to model a permanence is futile. Instead it gives you and your clients tools to a) reduce expansive dependencies by querying only for data you need and b) identifying which dependencies are used and how frequently allowing you to deprecate attributes safely.

This is not a tool meant for enterprises abusing rest apis as "contracts", where every change needs to be communicated in advance yadda yadda. It's targeted towards consumers who are ok with and actually _want_ a richer api in lieu of the stability provided by versioned apis. Good candidates for this use case include internal teams and external, non contractual apis.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> To GraphQL there is also the opposite: Just move as much stuff as possible to the backend - make the frontend thin.

With that approach you also don't end up writing a lot of specialized REST endpoints for the frontend. You can just use the queries directly and output for example HTML (or json and render that into HTML on the client). You can also do a lot more queries at once, because the services backend have usually more bandwidth and less connection limits than a frontend running inside a browser.

You are full control of the queries. Only UI related data is exposed to the frontend.

One draw back is the frontend team wouldn't do any business stuff anymore. They would do more generic components that the backend can drive.

And depending on the implementation you need more server round trips.

On the other hand, there is less JS to load and execute by the browser, since the backend is doing most of the orchestration and rendering.

<comment><USER19> Servers are expensive, and if you do it all on the server, you spend more scaling. Clients connecting have their own compute resources that are effectively free in terms of growth of a system as a whole.

GQL allows for the client UI/UX to describe what it needs, and the backend delivers that, within the context of well defined data structures that can then be distributed.

There's a cost to setting this up, but in the case of Facebook or Netflix, absolutely worth taking on. For a few hundred users, not so much.

<comment><USER21> However, Frontends are also expensive when you look on other metrics. They consume battery for example on a mobile device.

> GQL allows for the client UI/UX to describe what it needs, and the backend > delivers that, within the context of well defined data structures that can > then be distributed.

In the other model, it is done in the same way, except it is being executed in the backend and not the frontend.

Both the frontend and the backend are general computing platforms, but they have different characteristics in terms of performanc, connectivity, control etc.

Most UI/UX requirements are not that specific that only a frontend heavy implementation will be adequate to fulfil the requirements.

Please keep in mind that back in the old days, when we didn't have JS in the browser, all html was rendered on the server and a thin client was rendering it.

And even in right now, sometimes there are architectures popping up that try to make the client thin and the push the majority of the computation to the backend: Like for example Google's Stadia.

<comment><USER19> I'm sorry, but the battery example just doesn't fly... the biggest battery usage is the screen, if the user is looking at their phone, they're actively using it.

Back in what old day? I've been at this since 1995, and have been using JS pretty proactively since 1998 or so, it's been 20+ years now. Computers are a considerably more powerful and power efficient compared to 1998.

If you want to be able to use the internet on an 80386 without a math co... have fun with that. I'll take modern tooling, with modern hardware.

<comment><USER21> Generating UX/UI in the backend doesn't imply to use old tooling.

React server side rendering, Vue's Nuxt, etc are all modern ways to render UX/UI in the backend for example. And there are more.

The discussion of rendering server side goes deeper than just performance or using a "modern" framework.

There is for example: how many teams can work on a single application at the same time and deploy independently features in an efficient manner.

How can we share business processing flow requirements between the web version of an application with the native mobile application counter parts in an efficient way, without implementing everything three times.

Or other aspects mentioned here, like predictable performance etc.

Or choice of language, in the backend your choice of languages to choose is greater and/or simpler than in the frontend.

You can add more monitoring in the backend about aspects of your application than you can do in the frontend.

Obviously, the frontend has advantages as well. I.e. if something needs to be calculated, animated it is almost instantly available to the user when done in the frontend.

Frontend can perform functions offline, can use device specific features: like camera, contact list, push notifications etc.

Thus I prefer to look at the requirements and pick the tools for the job that best fulfils all the requirements for a giving application in a given organization and strategy.

If that means i do more stuff in the frontend, sure fine. But I wouldn't go for GraphQL just because it is "modern". Being "modern" is not solid reason to choose a technology unless you want to attract developers that like "modern" technologies. Which could be a valid reason as well for some organizations.

<comment><USER19> And you don't think server rendering has a cost? Running a very rich UI client side allows for tens of thousands of users per server, your suggestion reduces that to dozens or a couple hundred. Meaning many times more servers... more servers to configure, support, orchestrate, pay for. Meanwhile the clients are idle resources that could have been used.

If _you_ are the one paying for the servers, and you want to pay for 10x+ the servers to support your app, feel free.

</comment></comment></comment></comment></comment></comment><comment><USER22> How much bigger did the request bodies become?</comment>


A Proposal for the Dartmouth Summer Research Project on AI (1955) [pdf] - <AUTHOR> http://jmc.stanford.edu/articles/dartmouth/dartmouth.pdf <comment><AUTHOR> Topics back then included:

\- self-programming computers

\- natural language

\- neural nets

\- computational complexity

\- self-improvement

\- representations (ontologies)

\- randomness and creativity</comment>


Ask HN: Posgresql JSON or MongoDB? - <AUTHOR> I am building some app where part of it will have pretty much unstructured and changing data which I would like to dump as JSON. As a primary DB I am using PostgreSQL. I have never used JSON field type, but have used MongoDB before. I don't need anything fancy, 99% of the time it will be just storing and getting the data and querying by some fields of the JSON and it is of a scale that one instance of PostgreSQL could handle, nothing epic.<p>My question is, is PostgreSQL JSON field comparable to using MongoDB? Are there any limits or stumbling blocks that I should now about before choosing PosgresSQL for this? And is there an easy way to view and edit that JSON field by hand like I can when using Studio 3T app for MongoDB?(I know PostgreSQL DB apps are not the greatest for some reason..) <comment><USER2> Make sure you're using at least PG 9.5, which includes operators for modifying JSON values: [https://www.postgresql.org/docs/9.5/static/functions- json.ht...](https://www.postgresql.org/docs/9.5/static/functions- json.html#FUNCTIONS-JSONB-OP-TABLE)

I know nothing about Mongo, but one thing you won't get with Postgres is indexing inequality operations on arbitrary JSON fields. (You can accelerate equality and membership on arbitrary JSON fields using GIN indexes, and you can index inequality on fields known _a priori_ with expression indexes, but not both.)

Also note that locking is at least at a per-row granularity, there is no way to contend only _part_ of a JSON structure. Again, not sure what Mongo does here.

Likewise, updates are at a per-row granularity. This means that – assuming your JSON is indexed – you lose the benefit of HOT updates ([https://github.com/postgres/postgres/blob/master/src/backend...](https://github.com/postgres/postgres/blob/master/src/backend/access/heap/README.HOT)), which can result in a lot of vacuuming and indexing overhead if you have an update-heavy workload. Best practice here would be to place indexed and unindexed parts of the JSON objects in different columns, to regain HOT update optimization for updates to unindexed values.

<comment><USER3> Mongo seems to lock on various granularities. Sounds like collection ("table") is common and with WiredTiger engine (default iirc) it goes to document locking ("row").

[https://docs.mongodb.com/manual/faq/concurrency/](https://docs.mongodb.com/manual/faq/concurrency/)

<comment><USER4> WT is the default storage engine and it locks at document level ("row")

</comment></comment></comment><comment><USER5> Postgres JSONB is strictly better performing on a single node than MongoDB. You can also create triggers and things to properly validate your data and do other cool stuff you can't with Mongo.

There is literally no reason to ever use Mongo for a small-medium project anymore.

If you need tooling, check out the new pgAdmin 4: [https://www.pgadmin.org/](https://www.pgadmin.org/)

<comment><USER3> what about High Availability?

<comment><USER5> Just use Amazon RDS and let them deal with it.

None of the theoretical scaling benefits of Mongo outweigh the clusterfuck of maintenance, data inconsistency, and other general problems that shitty, shitty piece of software has.

<comment><USER3> name checks out.

I didnt mind mongo in a couple of my previous jobs. We never noticed data issues and we did some crazy things like generating mongologs on one machine and moving them to another manually .

</comment></comment></comment></comment><comment><USER6> Postgres is amazingly powerful if you want to get into it, and its near obsession with ensuring that everything is correct ensures a level of reliability that is typically not present in the MongoDB / MySQL world.

However that does result in much of the tooling not being able to support all of the features, unless they simply pass you down to SQL commands. Most of this is due to the MASSIVE feature set that Postgres supports. I use JetBrains DataGrip for Postgres work (which is SQL command based) , where as for MySQL i do most work with Sequel Pro (Typical MySQL GUI).

I am working on a reporting data warehouse right now using Postgres, and we are storing all data as JSONB objects as an abstracted "Entities" which link to other "Entities", where I am trying to get some of the advantages of triple stores / graph databases, while keeping compatibility with SQL / RDBMS which our developers and systems are used to integrating with. I think postgress is the best starting point for this project, simply due to the ability to manage the DB consistency inside the DB using triggers and stored procedures. While I am dealing with many different structures, I still need to be able to have a certain "sub-schema" of properties to be able to link the data to other data, which I can enforce using PGSQL.

However if your literally looking for something to Stash and retrieve a JSON object by primay key... your not going to get that much value from Postgres. There is some benefit if you already have pgsql infrastructure, as MongoDB can have some caveats around reliability (at least with the older versions). This is not that it is difficult to set it up in a mostly reliable fashion, it just requires some attention. However it will really come down to is your requirements, knowledge of the tools and use case.

</comment><comment><USER7> Use Postgres 9.6 JSONB. Trust me no one has ever looked back and said "I wish I had used MongoDB instead of PostgreSQL".

<comment><USER8> You said "pretty much". So use PostgreSQL 9.6 and but use JSONB only for the schemaless data but normal typed columns for the rest. And remember that JSONB is a column type so don't try to store too many different things in a one- column table. You can have as many tables as you need to sensibly organize your data, and then as many non-JSONB columns as you need for things like meta-data. For instance, date created, date changed, who created it, who changed it, is there an audit log for this table, when was it last replicated, backed up, etc. And then, think about whether you should just stuff all the data into one JSONB column or several.

For that matter you could have both a JSON and a JSONB column. If you run into data that is not well-formed JSON then you will get an error trying to insert it into a JSONB column but it will INSERT just fine in a JSON column allowing you to deal with the well-formedness problem later.

And do make use of the rich selection of JSON and JSONB functions to create indexes on your tables because nothing speeds up querying like an index that lets you filter your data and only process the important subset.

PostgreSQL has been undergoing some heavy development in recent years as more and more companies shift away from proprietary commercial databases. There are several companies offering full commercial support for PostgreSQL if you need/want that.

This development work is leading to a constant stream of improvements, both performance and new features. This alone is a good reason to choose PostgreSQL. It now embraces both the SQL schema world and the schemaless NOSQL world in one database system.

</comment></comment><comment><USER9> I've been using CouchDB since 2009 or so and am pretty impressed by the jsonb functionality built into PostgreSQL (the RDBMS I generally use for everything). I'm building an application with an abstracted "store" and will be running benchmarks against both in the next few weeks but so far, it looks like PostgreSQL might be a bit slower when writing jsonb fields. For this application, the ease of using just PostgreSQL (versus a hybrid PostgreSQL/CouchDB back-end) is well worth that slight penalty.

</comment><comment><USER4> This might be useful for you.

[https://www.mongodb.com/compare/mongodb- postgresql](https://www.mongodb.com/compare/mongodb-postgresql)

</comment><comment><USER10> If you're already using Postgres then just use that. If it doesn't work out switch to Mongo. No sense in adding another layer of infrastructure and complexity if you don't need it.

</comment><comment><USER11> If you already have PostgreSQL and only need limited indexing against the JSON, I'd use that... If you're looking for a document datastore for HA and/or read/write scaling, then I'd look at RethinkDB or MongoDB. I like RethinkDB better (as do many), it's currently pretty stable, I'm hoping to see some development pick up. There was some scare late last year as the backing company shuttered, but it's now under the Linux Foundation, so should see continued support.

</comment><comment><USER12> I'm working on a tool for visualizing data that works with MongoDB [1] . If you are working with JSON data anyway, mongo feels like a natural choice.

[1] [http://www.visualabs.com/](http://www.visualabs.com/)

</comment><comment><USER13> be careful: UPDATE operations are nightmarish compared to mongo at least for some use cases, as this one: [http://stackoverflow.com/a/42434665/244058](http://stackoverflow.com/a/42434665/244058)

</comment><comment><USER3> I'm also curious if anyone has tried JSON types in Amazon PG compatible Aurora or RDS?

<comment><USER14> We have been using JSON on RDS extensively since 9.5. Today probably 80%+ of PG JSON capabilities are used by the app in some way for some pretty complex use-cases (fintech). Never had any issues with this on RDS - everything just works (multi-as, read replicas, performance profiling etc) and we love it. Haven't tested Aurora yet.

<comment><USER3> Ok you've been using postgres RDS? Im mostly interested in Aurora.

It seems cockroachdb, aurora and cosmos are targeting similar use cases.

<comment><USER14> We use Aurora for MySQL apps and love it. The PG-compliant variety is not available in our regions, so can't put it through real testing by ghosting requests yet.

IMO RDS is perfect for most use-cases. I'd strongly encourage to try it out - it's highly performant and very reliable (uhhh... well...). Aurora has a significant edge under very significant loads (i.e. >300 concurrent clients), but can be slower under typical scenarios (0-100 concurrency).

</comment></comment></comment></comment><comment><USER15> in 2017, any db without horizontal scaling that is native is not really the best selection for large scale apps.</comment>


Shingled Magnetic Recording 101 - <AUTHOR> http://www.tomsitpro.com/articles/shingled-magnetic-recoding-smr-101-basics,2-933.html <comment><USER2> It's a neat hack but I just can't wait for spinning media to have the same kind of nostalgic feeling to them as CRTs do.</comment>


Car Dealers Wince at a Site to End Sales Haggling - <AUTHOR> http://www.nytimes.com/2012/02/11/your-money/car-dealers-wince-at-a-site-to-end-sales-haggling.html <comment><USER2> Thought I'd give my $.02 on this. I'm CEO of CarWoo! and we are right in the middle of disrupting the space and you guys are right it is extremely difficult, but it is possible. It's not so much of a disruption as it is an effort to level the playing field and bring an online buying experience to car buying.

It is possible to innovate here, you just have to do it the right way, within the laws that have been setup to protect the consumer and the dealer. It doesn't have to be a race to the bottom. What we see on CarWoo! are dealers offering market competitive prices and then competing with each other on things outside of the vehicle price. Things like professionalism and responsiveness become extremely important when all other things are equal (price and vehicle). Over half the consumers on CarWoo! buy from a dealer who didn't have the lowest price. A race to the bottom only exists if the only dimension visible to the consumer is price. On CarWoo! we emphasize the customer experience you're likely to get from the dealer which adds another dimension to the decision. Dealers love this, so do buyers.

The big issues in question are the brokering laws (getting paid a fee to refer someone who buys a car), privacy issues and dealership advertising laws (all vehicle offers must come with a vin and stock number). From day one at CarWoo! we have been keenly aware of these issues and worked within the rules to provide a highly valuable consumer experience, while working within the laws. It is absolutely harder to do it this way, but it can be done.

We don't believe haggling will ever go away, even if manufacturers move to a "single price" system like Scion. There is a distinct advantage for one dealer to break the rules and provide a lower price, so they will and the single price systems break down. We see Scion dealers discounting all the time, by the way. The only way to break out of this if you're a dealer is to be better at customer service and cater to your buyer's specific requests. Automation can not solve that problem, so selling cars will always have a dimension of personal touch and relationship.

What needs to be in place is a platform where buyers can shop multiple dealers online and dealers can work out the details of their car purchase before they show up at the store. This let's great dealers shine and helps them keep their margins in a highly competitive market. This is what CarWoo! provides and we've done it within the complex and ambiguos web of rules in this space. Innovation is possible here, and yes it is extremely hard. Harder than I ever imagined. But that's why it's such a huge opportunity.

<comment><USER2> One other thing I'd like to point out is the laws surrounding dealership advertising and brokering are extremely important to protect the consumer, therefor the scrutiny in the article. We agree with the laws and they do need to be in place. Here is why.

Dealership advertising laws require a vin/stock number and an expiration date to come along with all price offers. This protects the consumer from bait and switch problems which are rampant in this space. Without these protections dealers and vendors can simply make up prices to draw people into the store and when they show, switch them to something else.

I understand in depth the challenges involved in doing this right from a product standpoint and it would be orders of magnitude easier to provide a product that doesn't include a vin/stock number (a topic for another post). But the problem is consumer perception is wrong and misleading. If someone comes to my product and car buyers can get prices on a vehicle that may or may not exist (no vin/stock number) you are enabling bait and switch scenarios. On CarWoo! you will not have this problem, all offers have a VIN/Stock number and an expiration date.

Brokering laws (getting paid a referral fee from the dealer when someone you sent to the dealership sells a car) are also in place to protect the consumer. I had one of our ex-dealers that work for us explain this to me, because at first I didn't understand why this was a consumer protection issue. He used this example. It may be a bit out of date, but it illustrates the point. Let's say you're in a town with three or four car dealerships and the preacher in the town establishes a relationship with one of the dealers where the dealer will pay the preacher $500 for every customer the preacher sends their way that buys a car. On Sunday this preacher uses his influence to recommend people should buy from his favorite car dealer. The people in the congregation listen and when they go to buy a car, they go to the preacher's favorite dealer. The preacher gets paid, the dealer marks up the car $500 to pay the dealer and the consumer essentially paid $500 more than they had to. The brokering laws are in place so disclosure about the financial relationship between the buyer, the dealer and the broker are transparent.

Essentially you can get a better deal as a buyer without a broker and you should know upfront that's the case.

Hope this helps, it's taken me four years to understand all this stuff.

<comment><USER3> The article mentions franchise laws. What is your opinion on those?

</comment></comment></comment><comment><USER4> The real interesting point in all of this to me is how hard it is to innovate in this space on account of state legislatures essentially subsidizing car dealerships.

"So, after several dealers' associations complained that TrueCar was violating various laws, regulators from several states told TrueCar that they questioned the site's business practices. Honda Motor Company also protested loudly, threatening to cut off marketing dollars to dealers that did not follow its guidelines when promoting its brands on TrueCar's site."

While I know that there are a lot of people employed by local dealerships in the sales department, I can't help but thinking that a lot of these jobs essentially add a percentage cost to new cars with no value added. Which, of course, means that since innovation is a threat to these old business models, most of these dealerships will only be doubling down on legislation and protectionist policies that stop or slow genuine innovators like the guys at CarWoo and TrueCar.

<comment><USER5> If they don't, there's another 1.2 million jobs lost to technology in a country that has no answer to the growing imbalance between working-age population and gainful employment opportunities. Progress can be a very damaging thing for society on some levels.

I'm tempted to delete this comment because of the quick downvotes, but I'm not going to. I think it's a valid thing to think about at the very least.

<comment><USER6> I think about it all the time. Especially at the supermarket when I see the automated checkout line.

Then I head directly for the automated checkout line and tell my wife that the main reason I use those is because I like the idea of computers putting unskilled labor out of work, because I'm a bastard like that.

All the more reason we need to support education from an early age and more importantly get back to supporting journeyman and trade education -- so we have less unskilled labor.

<comment><USER7> Is a pain in the A. to use the automated checkout line though. It just ends up taking me longer so I don't really see the benefit.

<comment><USER6> The main benefit for me is that because most people are afraid of them or don't see the benefit, the line is shorter. When the regular line is shorter, I still use them.

<comment><USER7> If you have two or three items sure. But when you do a full shopping is a pain.

<comment><USER8> This is probably a style thing - I shop 3-5 days a week on my way home, which means I never buy more than a bag or 2 of grocs and the automated machines are always faster. It also keeps things lighter on the walk home, and food fresher.

This is probably not a choice i'd make if I didn't live in a city and commute by bus and bike.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> If the article has it right, the car dealers and manufacturers are complaining that making the market more transparent and open will kill the industry. These companies seem to believe the basic laws of economics don't apply to them.

If you assume a simplified, econ 101 model, a competitive and transparent market will drive prices down to the point where most firms are making a low but sustainable profit. It should never drive prices down to the point where most firms are losing money in the long run.

Now, the real world is more complex than econ 101. But even so, I can't imagine a scenario where transparency and competition would have the long-run effect of putting an industry out of business. If all car dealerships were totally transparent about their pricing, and buyers could easily view pricing data from every dealership, how would that force dealerships to price cars below cost? A race to the bottom does not assume a bottom of zero, or even a bottom that's below sustainable levels. Rather, it should imply a bottom where companies make a small, but reasonable profit.

<comment><USER10> It could, however, put some of the less-well-run dealerships out of business. The equilibrium number of dealerships might be smaller than it is now, as reduced margins support fewer salespeople. I'm not saying that's necessarily a bad thing overall, but I can see why the dealers might not be too keen on it.

<comment><USER11> Hardly, they have great marketing, but not exactly bare bones pricing. They cost the dealer 300$ for the sales lead which means their price is always higher than what a dealer will do directly. Last time I checked they where 600$ above what the dealer was willing to offer after a few minutes of haggling. Though, it's not a bad price if you hate haggling.

Hint, most dealerships make more money from their service departments than their sales floors. Use that to your advantage when buying a new car.

</comment></comment></comment><comment><USER12> "Car dealers have haggling advantages over purchasers: - You buy a car perhaps once every three years, perhaps once every ten."

Correct, this is no different than the mattress industry or bridal industry. There has to be a large premium over the price of the product to support the people operating the business. This is because there are established points- of-sale that were established before doing direct business with the consumer was reasonable, or because there is some additional value added during the sale by a physical presence (test drive, testing a mattress, getting fitted for a gown).

The remaining issue is eliminating the "icky" feeling that comes with buying a mattress or car. This could be eliminated if franchise laws could be repealed, but that's a hard battle. I believe Chrysler had set up a dealership recently in L.A. (to sell Chryslers, Jeeps, Dodges and Fiats), but dealers pointed out how it was illegal and had the state force that dealership's closure.

Imagine if there were brand-owned dealerships, that eliminated the haggle, leveraged their distribution networks to minimize the numbers of actual cars on their floor plan, and allowed customers to buy direct for a flat price. Would be nice, right? Actually, this _is_ possible, but it does involve a bit of legwork. I've bought my last two cars straight from the port of entry, but a lot of legwork is involved, as is developing a relationship with the right individuals. I should blog about that one day, as how to get around the nonsense of the mattress industry.

<comment><USER13> How is Tesla getting around franchising laws?

<comment><USER14> I don't believe Tesla has franchises.

</comment></comment></comment><comment><USER15> I actually love car shopping.

I enjoy making car salespeople squirm =)

Here's what I did the last time I bought a car. ($200 over dealer invoice, tax included out the door)

* I figured out the car I wanted ahead of time. Do not do a test drive with the goal of buying the same day. You will not get a good deal * This also included all the options that I wanted. GPS primarily * I started calling around the last week of month to various dealers within 100 miles. * I offered a price, if they didn't want to play, I gave them my number and rang off. * By the last day of the month, I had the price I wanted in hand and probably could have gotten another $100 off but that was at the point of diminishing returns for me. * Took a 2 hr lunch break to go to the dealership to deal with the paperwork. * 0% financing * Nice and stress free.

Same deal with mattresses. I shaved thousands off the list price.

Thing to keep in mind is that they are always going to win. The goal is not to beat them but to minimize their "win".

<comment><USER16> What kind of mattress costs thousands?

<comment><USER17> The kind that saves you money. ;)

Joking aside, a quality mattress can last for decades (and will often have a manufacturer's guarantee of such). The price of the mattress is surprisingly non-correlated with the annual cost of ownership:

<http://www.us-mattress.com/durability.html>

</comment></comment></comment><comment><USER18> As someone who's been through this process recently, I've never understood why car buying has to be this way. The whole process has a sleazy feel of I'll try to rip you off by as much as I can get away with. Car prices go lower as you reach the end of slow months when the sales teams don't reach their targets, they go higher earlier in the month .. it doesn't make any sense at all.

Why not just have an MSRP like the on the manufacturer's website and sell all cars at this price? The dealer can get a constant profit on the car price & servicing, buyers can feel less ripped off and everyone wins? It doesn't really have to be a race to the bottom..

<comment><USER19> Because (some) people like to get a "deal". And if you move your car brand to "no dicker stickers" and I don't, I'm likely to capture a share of the "likes a bargain" shoppers, though I admit I'll lose some of the "likes a sense of apparent fairness shoppers" to you.

Now, what happens when you have a "no dicker" policy and you need to move a car for whatever reason? Maybe the new models are coming out. Maybe the dealer needs to raise some cash to meet his loan payments. Maybe a model is intended for snow/foul weather usage, and you shipped too many of them into New England, expecting a normal winter. How do you entice customers who will eventually need a new car (according to them) into buying your car from your dealer now. Do you lower MSRP across the board for year-end models? That could work. Do you lower your MSRP only in New England? That could work, but smells worse from a globally consistent pricing point of view. Do you allow just the dealer who needs cash to lower his price? Well, you can't really do that and have any notion of consistent pricing.

And that's just the problems in the new car market, where a given car could be identical to any other any equivalent car. In the used car market, it gets way, way worse (in terms of complexity and sleaziness).

<comment><USER20> I mostly agree with your response, but it isn't entirely accurate. You can sale-price items that have a constant retail value.

If you see a sale in a supermarket, you don't think the price is inconsistent or that you need to haggle over cereal prices. You just realize it is a temporary sale, a discount on the normal price.

<comment><USER19> Agreed, but once you do that, you get away from tejaswiy's idea of just "sell all cars at that price". I don't have an issue with negotiated prices or sales, but some do.

</comment></comment></comment></comment><comment><USER21> Car dealers have haggling advantages over purchasers: \- You buy a car perhaps once every three years, perhaps once every ten. They sell a car at least once a week. \- You are basically alone; they are a team.

My sister started buying cars via fax quotes about 12 years ago. When she's figured out what she wants, she sends requests for quotes to every suitable dealer within 100 miles. (Now she uses email, of course.)

They still don't expect this minor effort to put them into competition with each other, and it seems to have worked in her favor every time. It's nice that TrueCar is automating this; perhaps more people will use it.

</comment><comment><USER22> I used CarWoo to buy my car. The price I paid was a clear $1000 under the "Great Price" that True Car suggested, and under the estimated Dealer Cost.

Nevertheless, I don't see these services as viable long term -- it's a race to the bottom. With manufacturer sales incentives, the smaller dealers are bound to get squeezed out by volume/commodity dealers.

<comment><USER23> Yes, but consumers generally like a good race to the bottom, even if everybody loses in the end.

<comment><USER22> I'm not one to complain -- I don't sell cars!

</comment></comment></comment><comment><USER24> It's not really that difficult to get a good deal on a car. The key is knowing which car you want ahead of time: make, model, color, and accessory packages.

Then, all you have to do is call all the local dealers in your area and ask for the "fleet manager." Tell the fleet manager your requirements, and ask for a selling price. (I've never had a fleet manager renege on the deal.)

As you call around, tell the fleet manager the lowest price you've been offered (don't lie) and see if they'll make a better deal. Continue this process until you've exhausted your options. Then walk in, complete the sales paperwork, go to the finance office, refuse all extras politely, and you're done.

<comment><USER25> yup. this works because it keeps the sales guys free to do their thing and the company would be stupid to turn down an already done sale.

</comment></comment><comment> X-Istence I use Costco's auto sale program. They give me a fair price and I don't have to haggle.

Now if only I had the money to buy the car of my dreams!

<comment><USER26> Note that these programs are often rebadged "aggregators". For example, AAA's "auto sale" program is Zag (Truecar). Costco's is Affinity Development, <http://www.affinitydev.com/index.html>

Not saying that anything is wrong with these, but just saying that if you trust AAA or Costco's internal controls and skills, you aren't getting those in these services. You are getting AAA or Costco's willingness to license their name.

As is posted many times in this thread, it's down to time vs. money. These services get you 1/2 to 3/4 of where you could get yourself, at a cost. You could do better, sometimes much better, with more time, but that's for each person to decide.

</comment></comment><comment><USER27> not really, car dealers make most of their money on their service department.

That new Civic might net the dealer a $500 profit....but if that car comes in for a single service, they'll net more than that from the repair. And yes you aren't paying any cash for warranty work...but the dealer gets paid by the manufacturer, so they don't care.

<comment><USER28> That's for dealerships. There's tons of small used car dealers that operate on empty lots or out of their garage. Their profit is derived solely from car sales.

<comment><USER29> ..and it's easier for them to make more than 500$ a car. Also, don't forget used car warranties.

</comment></comment></comment><comment><USER30> I'm in California and my credit union, and Costco have both offered this type of service for decades. You call up the service, tell them what type of car with what options and you'll get back some no haggle prices. I've purchased a car this way and the dealers that responded were mostly "fleet" dealers. I took this to mean that they didn't really deal with a lot of walk-in traffic and most of their sales was to businesses. Both sides save a lot of time this way. If you wanted to go further, you could take the price you get back from the service and call around to dealerships to see if they'll go lower but, for me, it didn't seem to get better unless the model was in particularly short supply.

I really don't see much fundamental disruption going on here, with the exception of maybe establishing this process in some states vs others with more limiting legislature, and possibly the amount of volume that goes the traditional way vs dealer competitive bids.

</comment><comment><USER31> As a first time car buyer one and a half years ago TrueCar gave me confidence during negotiations. In my case I didn't use it to determine a no dicker price with the dealer. Instead it was the basis for my walk away price and counter offer.

</comment><comment><USER32> Startup formula:

1) Identify a place where a middleman is taking a cut.

2) Find a way to disrupt or go around the middleman.

3) Profit.

</comment><comment><USER33> Car dealers also use pricing to get you to make a decision and buy a car. So another disadvantage to them is if the price is fixed it removes motivation to "buy now".

In the past fixed pricing has never worked and it actually works to the disadvantage of anyone who has a clue about negotiation. The fact that someone pays more is one of the reasons another person can pay less (dealers have to move vehicles).</comment>


Microsoft giving away free Windows phones to higher ranked Klout users. - <AUTHOR> http://klout.com/#/perks

<comment><USER2> Am I the only one who's never heard of Klout until now? To me, they've failed at their own service.

So for an individual, Klout just reaffirms one's ego and then rewards with special opportunities for consumerism?

<comment><USER3> I'm sure you're not the only one who hasn't heard of it until now, but I've been using it for awhile and it's actually pretty useful. I like their topics feature. I can see who the most influential people are in the "startup" topic and immediately start interfacing with them via Twitter.

I'm part of the 50% of Twitter users who are active every day, so I can see why if you're a part of the other 50%, or you just don't use Twitter at all, this wouldn't be very appealing.

</comment></comment><comment><AUTHOR> This is either desperation, great biz dev work from Klout or a smart way to get influential people to use Windows Phone.

I think the reason it's New York only could be that they want to target as many New York influencers as possible, then treat to them a concert. If they can get lots of influential people on Windows Phone it could spread in one of the largest US markets.

The question is does Klout equal influence and am I over analysing their intentions?

<comment><USER4> This seems like a pretty clever promotion. Worst case, it's not that expensive and there's no real risk. (Well, unlikely worst case: influential people get these phones, hate them, and tell everyone not to buy them. But Microsoft's data shows that when people try WinPhone they generally like them, so they can afford to take that risk.)

Best case: some actual influencers take them up on their offer and generate lots of influence about how great these phones are. And even if very little of that happens, early adopters (i.e. people who've heard of Klout in the first place) are likely to hear about the promotion, and generating even a little buzz among early adopters is a good thing for them.

And for Klout, having sign up and climb leaderboard = might get free stuff can only be a good thing.

</comment></comment><comment><USER5> Apparently my new phone is on the way and my spot is reserved (if anyone else is going and wants to meet up, I'm in NYC and picked the first day). I'm curious as to which phone it is, though; I've been looking to replace my HTC HD7, so I'm hoping that's not it, which I'm assuming it's not since that's a previous generation. I absolutely _love_ WP7, but the HD7's hardware is just not very good build-quality-wise. Pretty excited to try out something new.

</comment><comment><USER6> Can someone who logged in from facebook or twitter post a screenshot of the relevant page?

<comment><USER7> Basically it just comes up and says that I'm not eligible for the free Windows Phone, because I need a Klout of 55 and to live in New York, NY (easily cheatable with Twitter, I suppose). My "Klout" is only 20. Not sure where that puts me on the newbie<->Bieber continuum.</comment></comment>


User-Centered Product Management - <AUTHOR> http://whatusersdo.com/blog/user-centred-product-management/ <comment><USER2> Things I learned:

Listening to the users' explicit feedback is almost always a) at best pointless, b) at worst incredibly disruptive (in a bad way).

Watching your users use your product (in person!) is almost always enlightening.

None of these lessons are new; I'm sure they've been around since at least the 60s.

<comment><USER3> Agreed completely, Johansch.

Re explicitly following directions from users being a bad idea, Janna Bastow (of Mind The Product) says as much in her section of the article.

I think it's still important to gather feedback though—it's not the answer, but it can point you towards the right question.

I think, in broad strokes, the opinions are always going to be the same—i.e. get user feedback and do usability testing. But the nuances in how each person does those two things (and various methodologies applied) is where we can learn from each other.

<comment><USER2> Right. Don't immediately follow their very strongly worded suggestion for feature X, ask instead what problem Y they are attempting to get solved. Then use this this as one input out of many.

But surely this is old news to any prospective PM?

<comment><USER3> Right again. It is (or should be).

I personally enjoyed the parts where people discussed methodologies (user stories vs Jobs To Be Done, for example), than the broad strokes opinions.

</comment></comment></comment></comment><comment><USER4> Hard to take seriously a "User-Centered" article on a website that hijacks your browser's scroll.

<comment><USER3> Hi guys,

Really sorry to hear you're having an unpleasant experience.

Would you mind telling me which devices, OS's and browsers (or other relevant info) you're using when you encounter these issues?

If you work in UX or product (which it sounds like you do), you probably know no one ships a perfect experience (in spite of our best efforts). It's not due to negligence or bad intentions.

We've run several rounds of UX testing on our site and the overwhelming majority of people don't experience any scroll-jacking. There's obviously some kind of death-combo that causes problems for some users.

So, we're neither ignoring our UX nor trying deliberately to punish you. We would be in your debt if you could help us figure out what's going on here!

I suspect it's some kind of issue with Wordpress itself... but I'm no (hardcore) techie and can't seem to find the root.

<comment><USER4> Hey, sorry to be a jerk about it! I understand these things are not at all intentional, just kind of easily overlooked.

I looked into your code, and it looks like you guys use a javascript library called SmoothScroll v1.2.1. I'd suggest just removing that bad-boy. Good luck!

<comment><USER3> Omg, thanks so much, dude!

I'm gonna look into this first thing in the morning (it's way past working hours here in London).

I can't wait to get rid of that pesky thing :)

</comment></comment></comment></comment><comment><USER3> Hi @the_gastropod, @balero and @temp246810,

The scroll-jacking has been removed! Thanks for all your feedback.

Be sure to clear your cache before checking the article again and it should all be fine :)</comment>


Ask HN: Do you think market is crashing(recession) again? - <AUTHOR>

India, China, US top news today is about market crashing. I feel like deja vu from 2008. Is it going to happen again ? <comment><USER2> A downturn maybe, but probably not a full-on crash. Look at this: [http://www.multpl.com/shiller-pe/](http://www.multpl.com/shiller-pe/)

</comment><comment><AUTHOR> also [http://techcrunch.com/2015/08/24/facebook-down-12-1-apple- do...](http://techcrunch.com/2015/08/24/facebook-down-12-1-apple- down-10-google-down-6-5-microsoft-down-5-8-as-stock-markets-plummet/)</comment>


Show HN: SocialCla.us - Secret Santa groups with Friends - <AUTHOR>

Hey guys,
http://socialcla.us
A friend and I thought up SocialCla.us over the weekend and have spent the last few nights building it after work. SocialCla.us makes it easy to start Secret Santa groups with your Facebook friends.
Feedback is appreciated!
P <comment><USER2> I guess my only feedback would be to provide a little bit more information on how Secret Santa works through an online medium.

Oh and "Copyleft" in the footer made me chuckle.

<comment><AUTHOR> I had originally planned to try and integrate the Facebook gifts product into this but unfortunately it's not yet mature enough to do so.

We make it easy to facilitate the creation and organising of Secret Santa groups, not the actual gift exchange itself. That's up to users to figure out.</comment></comment>


Ask HN: Tips for Getting an SDR Role? - <AUTHOR> I am a recent grad that wants to break into startup sales. Any tips? <comment><USER2> Happy to chat if you want to email me!

Tips:

If you are looking for something more structured then I recommend you go to a bigger company that has a pipeline of inbound customers and has a very active marketing machine in place.

If you're looking for something more risky, find a series A company that has a growing demand. It can be messier but you'll learn how a company begins to develop a sales strategy and department.</comment>


Announcing Rust 1.0 - <AUTHOR> http://blog.rust-lang.org/2015/05/15/Rust-1.0.html <comment><USER2> I would like to take this opportunity to formally apologize to the HN community for that time back in early 2012 when I predicted that Rust 1.0 would be released "in about six months or so", and later proceeded to proudly proclaim that 0.4 would be the last release with major breaking changes to the syntax. I hope you all can find it in your hearts to forgive me. :) But at long last, we did it, and it's almost too good to believe.

But as much work as it's been just to get to this point, the real struggle begins today. Months and years of brutal campaigning, compiler engineering, and careful language design lie ahead. If you've yet to take a look at Rust, please do, and report your findings so that we can better prioritize our efforts for the near future. If you like what you see, there's plenty of work to go around and a welcoming community should you decide to dig in and join us. And if you don't like what you see, that's fine too; Rust is not the language to end all languages! We're just here to make the world a little safer, however we can. Hopefully today is but the first page in that story. :)

<comment><USER3> It is an excellent achievement, congratulations!

For what its worth Java had an even longer gestation period and it wasn't until Eric Schmidt declared that we had to have 1.0 in Bert Sutherland's desk by 1/1/95 or "else" did it actually get to that point.

I'm really excited to start trying it out in earnest.

This is a bit disconcerting though:

       ls -lh
       total 588K
       -rwxrwxr-x 1 cmcmanis cmcmanis 8.4K May 15 13:02 hello_world
       -rw-rw-r-- 1 cmcmanis cmcmanis   83 May 15 13:02 hello_world.c
       -rwxrwxr-x 1 cmcmanis cmcmanis 565K May 15 13:01 main
       -rw-rw-r-- 1 cmcmanis cmcmanis   42 May 15 13:01 main.rs

I'd love to write a safe embedded system in rust and that is going to mean much smaller footprint for a 'hello world' level of program :-)

<comment><USER4> As you can already read in this thread (see [1]), this is due to static linking of the whole standard library. This limitation is known and solutions are being worked on.

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

<comment><USER5> Does Golang support dynamic linking? I think a Hello world binary in Go is about the same size? I know I'm sort of comparing apples with oranges here.

<comment><USER6> Yes, you can dynamically link by compiling Go with gccgo ([https://golang.org/doc/install/gccgo](https://golang.org/doc/install/gccgo)).

<comment><USER7> How? do you have tutorial/info about it? (The link above doesn't explain how.)

</comment></comment></comment></comment></comment></comment><comment><USER8> For anyone that hasn't played around with rust yet, this is why I'm excited about rust: [https://github.com/Azdle/hello- gtk.rs/blob/master/src/main.r...](https://github.com/Azdle/hello- gtk.rs/blob/master/src/main.rs)

That is a GTK GUI application that makes HTTP requests in under 40 lines of code.

Don't get me wrong I love all the safety gaurentes and what not, but just being able to write quick simple apps that would usually be a pain to write in C is a game changer for me. A lot of this is down to Cargo (the Rust package manager, very npm-like imo) and all the great rust libraries that already exist. I'm super excited to see where this goes now that it's 1.0, people can stop worrying about breaking changes in the language and just get down to writing libraries to do everything.

<comment><USER9> Why is that exciting? You've been able to do that almost line-for-line in Python for at least 8 years, if you're not bothered about the "safety guarantees and what not".

<comment><USER10> Rust is not a replacement for Python, but a replacement for C.

It's exciting that you can have power, portability and speed competitive with C, but with syntax and safety so good that you're comparing them to Python :)

<comment><USER11> > Rust is not a replacement for Python, but a replacement for C.

I think its a mistake to view any language as simply a 1:1 replacement for an existing language. Newer languages can have the greatest strength in an area currently dominated by one older language (say, Rust with C), and still be better for some applications where another older language would generally be preferred to the first (say, Rust being better than Python at some things where Python would generally be preferred over C.)

</comment></comment></comment></comment><comment><USER12> Now that Rust reached v1.0, I may finally look into it without the fear of wasting time to learn stuff that will change within next months. (It's quite sad, though, that recently released Debian Jessie won't have it in its main repositories.)

Allow me to ask some questions, because I cannot easily find the answers and they're IMHO crucial for wider Rust adoption:

1\. What CPU architectures/platforms Rust currently supports?

2\. What's the state of cross-compilation support?

Most of devs have workstation on i386/amd64, but some of us may work with ARM, PowerPC and other architectures. Rust's memory safety seems appealing for embedded solutions, but can it be used there already?

BTW The install page is not well-thought-out.

[http://www.rust-lang.org/install.html](http://www.rust-lang.org/install.html)

Unless I hover on the 32-bit/64-bit links and read addresses they point to, there's no way to tell whether it's for x86 or ARM for instance. And installation via piping script that is being downloaded to shell is something that shouldn't be present at all.

<comment><USER13> 1\. In a sense, anything LLVM supports. Some stuff is more first-class than others, of course. We test every commit on x86, x86_64, and ARM.

2\. Exists, but isn't particuarly easy. The biggest hurdle is getting a copy of the standard library for the target platform, then it's pretty easy. It's gonna be a focus in the near-term.

<comment><USER12> Thank you for such a prompt answer.

EDIT:

Quick googling revealed that Rust doesn't work with musl libc yet. It will be really nice when it will be fixed.

<comment><USER13> There is actually preliminary support: [https://github.com/rust- lang/rust/pull/24777](https://github.com/rust-lang/rust/pull/24777)

Making this work well is a very high priority.

</comment></comment></comment></comment><comment><USER13> Thank you so much to all of our community and contributors. It's been a long time coming, but I'm really proud of what we've done together.

I'm finally going to get some real sleep tonight, I think.

</comment><comment><USER14> This is so huge!

Rust is going to be the first time I am going to learn a programming language from the day it is born (until now it was tough to learn Rust, given the changing APIs ;).

I see a bright future for Rust. Thanks to Mozilla and the whole community for making it possible.

<comment><USER15> I wish there could be a site started by the very beginner's to document the learning and adventures one gets from this. I wish it could have people of various expertise, from those never having learned a single language to those with several languages under their belt. I would have a fun time learning alongside them. It will be just like high school all over again.

<comment><USER16> The book "The Rust Programming Language" is really solid and everyone learning the language should read it.

</comment></comment></comment><comment><USER17> Congrats to the team and thanks for your hard work! I'm not a Rust developer but it's definitely piqued my interest in doing more native development without being afraid of introducing buffer overflows and other security exploits.

</comment><comment><USER18> Awesome! I assume you intentionally released this on a Friday just to eat up everyone's weekends :) Thanks for the hard work. As I dig in, I'm hoping that Rust will fit in the "useful and safe" sweet spot in Simon Peyton Jones's diagram here: [https://www.youtube.com/watch?v=iSmkqocn0oQ](https://www.youtube.com/watch?v=iSmkqocn0oQ)

<comment><USER13> > I assume you intentionally released this on a Friday just to eat up > everyone's weekends :)

Hehe, we didn't choose it for any specific reason, but when we started to do the six-week cycle, it landed on a Friday. I like shipping on Friday for a number of reasons, but there's good reason to pick any particular day.

<comment><USER19> I actually liked it for selfish reasons. I got to stay out way past my bedtime and geek out about Rust at the Boston meetup. :D

</comment></comment></comment><comment><USER20> If you haven't played with Rust yet and are looking for some puzzles to help motivate you to learn, we've updated our Bloomberg CodeCon[1] site to support Rust 1.0. You can login and click the "Challenger Series" to get 17 problems of varying difficulty to solve in Rust.

[1] [http://codecon.bloomberg.com/](http://codecon.bloomberg.com/)

<comment><USER21> Requires Twitter or Google+ login. (For me that gets an instant back-button, and the fact that one can't see _any_ of the actual content of the site before logging in makes it worse. But I expect there are good business reasons for it. Anyway, I mention it here because it may save a click or two for others who share my prejudices.)

<comment><USER20> If you don't want to login you can get most of what you're looking for here -- the content used for the finals (questions) along with the solutions.

[http://codecon.bloomberg.com/2015-finals](http://codecon.bloomberg.com/2015-finals)

</comment></comment></comment><comment><USER22> Well done! I'm generally against shoehorning languages into environments where they don't belong, but I can't wait to try using Rust for webdev.

<comment><USER23> With the large box flexibility you get with webdev, I don't know why you would want to use it except for specialized parts. Like a RAW -> jpg transcoder.

<comment><USER13> One reason: really, really low resource usage. Crates.io is reasonably complex, linking to libgit and such, and still uses roughly 25MB of RAM, constant. A Ruby process is ~30 MB off the bat last I checked, and Rails, well...

<comment><USER23> But how does it compare to go in this case?

<comment><USER24> Haven't made any direct comparisons (and that would be hard) but from my experience from working with both I would say that you probably won't notice a big difference in RAM usage (< 10% difference).

</comment></comment></comment></comment></comment><comment><USER25> Congrats! I've been excited about Rust for a while now, and this gives me a good reason to look into it a bit more. A quick question, though, if it's appropriate in this context:

It seems to me that the borrow checker disallows behavior that I (perhaps naively) wouldn't be concerned about. For example, if I have this C snippet:

      { // Safe C
        int *ptr = NULL;
        int val = 42;
        ptr = &val;
      }

Everything is hunky-dory. Translating this to Rust results in this (I think):

      { // Malformed Rust
        let ref: &i32;
        let val = 42;
        ref = &val;
      }

Now the borrow checker tells me that "val" doesn't live long enough, because the reference comes to life before the value. It seems like this should be safe behavior, because the reference isn't bound to the value until after the value comes to life.

Can anyone shed some light on this for me? I'm all for safety, but this in particular seems like something that I should be allowed to do.

<comment><USER26> I'll assume you meant 'ref = &x' in your example.

But what happens is that variables leave scope in reverse of the order in which they came in, so ref lives for slightly longer than val.

This happens so that the order of destructors can be guaranteed.

<comment><USER27> refs don't have destructors.

This happens because borrow scopes are always lexical. This is a bug, see [https://github.com/rust-lang/rfcs/issues/811](https://github.com/rust- lang/rfcs/issues/811).

<comment><USER28> Bug =/= language feature that we want that hasn't been implemented or designed yet, FWIW. Right now the borrow checker is currently performing to spec, but the spec is just a little too restrictive in some cases.

<comment><USER29> "Bug =/= language feature that we want that hasn't been implemented or designed yet, FWIW."

In this case, I think the term is justified.

</comment></comment></comment></comment></comment><comment><USER30> It's always exciting reading Rust posts on HN, so very happy about a stable release!!

I can't help but feel the language has a very steep learning curve, however; doing something like making an event-queue-with-callbacks is very hard to write out in Rust if you're a beginner with just the current docs.

I think Rust will benefit greatly if their docs compiled some articles on how to write typical systems-related code (for me, I would love to see how to implement task queues with callback mechanisms).

</comment><comment><USER31> Congrats Rust team, and perfect timing, got some vacation next week and plan to build some things.

</comment><comment><USER32> I thought 1.0 was announced a few weeks ago. Am I going crazy? I mean it's awesome news I'm just confused.

Edit: looks like I'm going crazy. It seemed so vivid too like I actually started checking out the rust documentation and was looking for a book to pick up. Unless everyone is messing with me...

<comment><USER33> It seems you might be suffering from the Mandela Effect. Do you remember it being the Berenstein Bears or the Berenstain Bears?

<comment><USER34> This is blowing my mind. I remember Berenstein Bears as well.

</comment></comment></comment><comment><USER35> Thanks so much to everyone who contributed to this milestone. Rust is one of the few pieces of new technology that has made me want to drop everything and dig in to it.

It's also one of the few open source projects that has actually gotten me to contribute.

</comment><comment><USER36> I'd like to give special thanks to Daniel Micay, whose contributions are a major reason Rust is even remotely tolerable.

</comment><comment><USER37> Awesome! Now to get the STL docs up to speed and fix them up so that they're less ambiguous to newcomers!

<comment><USER13> The STL docs? And what specifically is ambiguous? (and thanks :) )

<comment><USER38> I think the main problem with the docs right now is that most people looking at them aren't just new to the API, but also new to the lang - it can be quite hard to navigate them if you don't know much about the type system and how APIs may be composed using Rust's various facilities. That is obvious, I guess, but it doesn't stop people from trying.

Some way to conflate the two types of docs might be cool. For example, if there were high-level examples of commonly used API patterns in the std lib ("we use traits in this fashion here to achieve the following goals"), the docs could embed links to them as factoids ("this is an application of <this pattern>"). Heck, even just a ? button next to the "Traits" header linking to the book's Traits section would probably help some folks.

Linking to rust-guidelines in some way to back up the design of various APIs might be cool, too.

(Don't want to be the guy to crash Happy Day with more requests, so I'll just add: Many thanks for all your work, Rust has been tickling my brain in enjoyable ways like nothing else this year.)

<comment><USER13> Yeah, it's very true. Markdown is really weak in this area too, requiring us to a do a LOT of manual wor to link things up.

Oh, and rust-guidelines actually moved in tree: [http://doc.rust- lang.org/stable/style/](http://doc.rust-lang.org/stable/style/) They haven't yet been linked because of all the FIXMEs.

Thanks for the suggestions. :)

<comment><USER39> Just out of curiousity, why not use reStructuredText?

<comment><USER13> We had a long, hard think about it. We had a fairly significant amount of Markdown, the tooling was already written, and on a more personal note, I like the idea of reStructuredText, but I _hate_ writing it. If we'd have overwhelming reason to switch, we still would have, but basically, that's why: not enough reason to overcome momentum.

ASCIIDoc or something else might be nice too.

</comment></comment></comment></comment></comment></comment><comment><USER40> This has to be the fastest post to rise to #1 on HN I've ever seen!

<comment><USER41> The fastest I've seen was Steve Jobs passing away.

<comment><USER42> those were the fastest 20 posts.

</comment></comment></comment><comment><USER43> Is there anywhere I can download a Rust tutorial in kindle format? I'd like to start learning Rust this weekend.

EDIT: To answer my own question: [http://killercup.github.io/trpl- ebook/](http://killercup.github.io/trpl-ebook/)

</comment><comment><USER44> Good news everyone! :) I really hope this language gets traction.

</comment><comment><USER45> Great! I just downloaded and installed it, and my programs still worked!

No more "cargo clean; cargo update; cargo build; cargo test;" every day! At last.

<comment><USER46> install my `cargo-do` utility and it can be `cargo do clean, update, build, test` instead ;)

github.com/pwoolcoc/cargo-do

</comment></comment><comment><USER47> Let me begin by saying congratulations to the Rust team and supporting community. I've been following Rust when I realized it would make for a good language to try with robotic controls (due to all the safety stuff). Stupid question time: What does this release mean for the embedded / control systems community? Will you be recommending any specific boards / micros / libraries from now forward? If so, which?

<comment><USER48> The story for rust in embedded contexts is not quite finished. There are dozens of people writing kernels in rust, there's zinc for arm microcontrollers and I've seen projects for raspi and PSX, so stuff works. It's not great yet, though. Once the allocator api is added to the stdlib it'll be much easier to use the standard library in embedded contexts. There's probably other stuff I don't know about but I know for sure that this is a priority for the near future.

<comment><USER49> My current approach to the heap problem (I'm working on a toy Rust kernel) is to compile the allocator portions of the standard library (liballoc) with a configuration flag that makes them use a particular set of external functions as the low-level heap allocation machinery. Then, my kernel provides these functions, and all the nice stuff (Box, Vec, etc.) "just works".

IF you're curious, the relevant code is at [https://github.com/krzysz00/rust- kernel/blob/master/kernel/m...](https://github.com/krzysz00/rust- kernel/blob/master/kernel/malloc.rs) . The functions that start with "rust_" are the allocator interface

<comment><USER48> That's much easier than I thought it was! I'll have to start working on my kernel again.

<comment><USER49> You can find some more {complex, idiomatic, not terribly hacked together} Rust kernels at [https://github.com/thepowersgang/](https://github.com/thepowersgang/) .

</comment></comment></comment></comment></comment><comment><USER50> Very cool. Going to try to learn some basics this weekend! Exciting times watching (from a spectators points of view) the evolution of Rust to this point. Sounds like more exciting times ahead.

</comment><comment><USER51> Congrats Rusties. I've just begun playing and it seems worth the time investment.

<comment><USER52> Rustacean* :)

<comment><USER53> Rustafarian

<comment><USER13> The community generally doesn't like that name, as it has awkward, appropriating connotations.

<comment><USER54> What, and Rustacean doesn't? When we Uplift our Cetacean friends, is this sort of awkward appropriation _really_ how you want to meet the newly-conscious masters of 3/4s of the planet?

( _Cough_.)

<comment><USER55> I parse 'Rustacean' as appropriating crustaceans, not cetaceans. I'm rather less worried about annoying them, because i eat enough prawn toast that i'm already on their shitlist.

</comment></comment></comment></comment></comment></comment><comment><USER56> It mentions the rust 1.1 beta, but doesn't link to it. Where is the list of changes in 1.1?

<comment><USER13> As per [https://internals.rust-lang.org/t/release-channels-git- branc...](https://internals.rust-lang.org/t/release-channels-git-branching- and-the-release-process/1940) , there's a branch: [https://github.com/rust- lang/rust/tree/beta](https://github.com/rust-lang/rust/tree/beta)

I don't think we currently have a changelog or anything: we were mostly focusing on this new, stable branch this time around. You're right that making a changelog now would be super helpful, I'll add that to the list for next release. Thanks!

</comment></comment><comment><USER57> I always disliked - "let and let mut".

Personally - "val and var" are more intuitive.

<comment><USER58> The reason is that "let" takes a pattern, and mutability is an attribute of each pattern binding, not the let statement.

        let (mut a, b) = (..., ...); // a is mutable; b is not

<comment><USER57> Makes sense, but my brain fires wrong visual signals when I see "mut".

If the whole point is to name a memory address - mutable or immutable. Why not have a special name for the address itself ?

e.g: a = immutable, #a = mutable.

<comment><USER59> Your brain should fire wrong signals when you see mut. I think part of the design of mut is to discourage you from abusing mutable variables. (Personally, I prefer F# forcing you the type mutable).

I'm glad they didn't give it a special prefix because not only would it add unnecessary noise, it would make refactoring tedious. I'd rather give the compiler my intent once, and let it figure out if I violated my own intentions.

One thing I like in the F# toolset is the syntax highlighters will highlight mutable and reference variables different colors. It's a matter of time before Rust developers have that (If they don't already).

<comment><USER57> "Discouraging Mutability" with the added "mut" would be a positive way to look at it.

Thanks !

</comment></comment></comment></comment></comment><comment><USER60> Why does a simple "Hello World" create a 578KB binary?

Is it packaging a lot of extras that aren't needed for such a simple program?

<comment><USER61> Hello world in C++ is 1.3 MiB when linked statically.

        $ cat helloworld.cpp
        #include <iostream>

        int main()  {
        std::cout << "Hello world" << std::endl;
        }

        $ g++ -std=c++14 -Os -static helloworld.cpp
        $ size a.out
        text    data     bss     dec     hex filename
        1294232   29692   92936 1416860  159e9c a.out

The majority of this is bloat from GNU libc though, using diet libc would yield better results

        $ cat helloworld.c
        #include <stdio.h>

        int main()  {
        puts ("Hello world");
        }
        $ gcc -std=c99 -Os -static helloworld.c
        $ size a.out
        text    data     bss     dec     hex filename
        725706    7572    9080  742358   b53d6 a.out

<comment><USER62> As I've pointed out in a previous thread, virtually all of it is from a) iostreams and b) glibc. If you don't statically link glibc (as is the case the vast majority of the time) it's much smaller.

Edit: You made my point for me in your edit :) Leaving my original comment for posterity.

</comment></comment></comment><comment><USER63> Congratulations to the team; it is nice to be around when a language is born. I remember when Ruby was born, and most people (that I knew) were like "Huh? Why Ruby, when we have Perl?".

I haven't followed Rust much, but as a total n00b: what are some _practical_ reasons why one would choose to learn Rust? What features does this language have which others (pick: C, C++, D, etc.) don't have? What does it do better than the aforementioned languages? (Please don't take these as a challenge, but as a desire to learn more). Thanks!

<comment><USER27> Rust manages to fight neck-to-neck with C++ on speed and runtime overhead ("fast" and "effectively none") whilst giving both safety and some really nicely made abstractions.

The one everyone mentions is that Rust gets memory safety without garbage collection. But there are cooler things, like being able to implement units in the type system. Rust also gets safety right in the sense that its defaults are good - its primary random number library has ChaChaRng and IsaacRng instead of a Mersenne Twister, for example.

The sensible library design goes everywhere, from Rust's functional roots, high-quality zero-overhead iteration protocol (none of the mess that C++ gives you) to simple things like a well-designed composable hashing standard.

Even stuff like comparing C++'s move, copy and constructor semantics are much nicer in Rust, and in most cases even lower overhead: everything is a memcpy and is implemented automatically.

I can go on. Rust is one of the few languages that IMHO gets string handling right, and has good unicode support from the outset. It's easier to write error-proof filesystem code than any other language I've used. Threading _isn 't_ a mess.

There are disadvantages, such as Rust being one of the hardest languages to learn. Generics are both pervasive and difficult - they're clean unlike in C++ but they're also uncomfortably explicit. There are lots of nonlocal typesystem effects, largely due to the thirst for safety.

But it's a good language. Definitely one of the most exciting I've seen in a while.

<comment><USER64> > Generics are both pervasive and difficult - they're clean unlike in C++ but > they're also uncomfortably explicit.

Maybe it's because I'm used to it, but do you have an example of why you think this? I think with type inference being pervasive, I've never been annoyed by generics. Additionally with type aliases a lot of pain can be avoided.

One of the ugly parts is that call-site type parameters, when given explicitly, have an ugly (but consistent) syntax. This is probably unfixable. Another annoying part is the lack of anonymous return types, which makes some types annoying to read or even impossible to express, but work is being done to improve this now.

<comment><USER65> > Another annoying part is the lack of anonymous return types, which makes > some types annoying to read or even impossible to express

Out of curiosity, impossible to express how? Can't one just store the return value in a variable, investigate its type, then copy-paste that as the function return type?

<comment><USER66> "Annoying to read" can be solved with typedefs, but there are types impossible to express.

At the moment I think closures are impossible to express as named types.

</comment></comment></comment></comment></comment><comment><USER67> Congrats! Thanks to all who worked on it!

</comment><comment><USER68> A real game changer although I wonder if there's still some minor breaking changes I'd like to see

<comment><USER68> Consider how nice it would be is if when you matched (a,a,a) it checked to make sure they were equal. Probably can't do that for (_,_,_)

It's a breaking change, but who would mind?

<comment><USER4> Well, do you mean equality by value or by memory location?

I also hope they are not too conservative in the beginning, because we might have to pay for mistakes for a long time.

<comment><USER69> Even if equality was by memory location in the case where the tuple contains pointers, one would still have to work out how equality would work for tuples of non-pointer types. For example, would (NaN, NaN) match (A, A)? If the implementation makes use of ==, then it wouldn't, and if it uses bitwise equality it would.

</comment></comment></comment></comment><comment><USER70> Congratulations to everyone on the team!

</comment><comment><USER4> I think the release of the first stable version is an appropriate time to ask how the collaboration with packaging teams from major distributions is going.

Can you give us some information on that?

<comment><USER69> There is a Rust package in Arch Linux's community repo, but it's still on the beta version, and there is no cargo package yet.

</comment></comment><comment><USER71> Rust is nice, but… Why can't anybody made a language with the exact syntax of Python, but compiled? It doesn't need extreme safety features or other buzzwords.

<comment><USER72> It's ridiculous of them to downvote you instead of providing an honest answer. This is a good question that I think a lot of Python fans might wonder about.

One of the many great things about Python (and other "dynamic" languages) is how flexible it is in so many ways. Instead of forcing you to be more explicit, make more decisions, and lock more things down in advance, it lets you get away with telling it to figure out a lot of things for itself while the program is running.

This kind of flexibility isn't free. It does a lot of things indirectly, it makes decisions for you and, if they turn out to need changing, it makes those changes as, and so on, while it is running, which requires a lot of computation.

You actually could compile Python, but keeping the "exact syntax" presumably means keeping all of Python's capabilities to be flexible at runtime, so compiling would require essentially building a lot of the Python interpreter right into your compiled app. This, in itself, would just change the packaging and wouldn't buy you much in terms of performance. A lot of clever people are looking for ways to speed up Python without removing features, but it will probably never be possible to make Python as fast as Rust will eventually be, nor to make Rust as convenient as Python.

</comment></comment><comment><USER73> I'm on a Late 2013 Retina MacBook Pro, running 10.10.3, with the latest stable toolchain. It would not compile.

[http://pastebin.com/bifK665u](http://pastebin.com/bifK665u)

I set --prefix=/usr --enable-debug

No dice. I also tried to build from source in a VM on that same machine. 32-bit Ubuntu 14.04.2 (3GB of RAM), latest stable toolchain. Again, didn't compile. Core dump.

<comment><USER74> That is strange; I bootstrap regularly with `--enable-debug` and have not seen an arithmetic overflow during bootstrap (at least, not for a long time).

It would probably be best to carry on a conversation on a formal bug report; did you file one at the url it listed?

</comment></comment><comment><USER75> Any IDE support for Rust ?

<comment><USER41> Hi! You are in luck! Today, this was posted: [http://blog.piston.rs/2015/05/14/Visual- Rust-0.1/](http://blog.piston.rs/2015/05/14/Visual-Rust-0.1/)

<comment><USER43> Windows only?

<comment><USER76> No shit. Visual Studio is Windows only.

<comment><USER43> Vusual Studio Code runs on Linux and Mac.

<comment><USER77> Visual Studio Code really has nothing to do with Visual Studio except that they share part of a name.

</comment></comment></comment></comment></comment></comment><comment><USER78> I was looking to see what UI and database bindings were available as crates and came across the crates.io web site.

It would be useful for people new to Rust to see what existing libraries are available and one way would be to have a link on the www.rust-lang.org site's font page pointing to crates.io site.

<comment><USER64> Also see: [https://github.com/kud1ing/awesome- rust](https://github.com/kud1ing/awesome-rust)

</comment></comment><comment><USER79> Would it be possible to achieve near-Rustiness with modern C++14 and tons of warnings/errors enabled?

<comment><USER80> Mozilla has several million lines of C++ code. Do you think they would invest substantially in creating an entirely new language with a new ecosystem and from-scratch Servo rewrite if their C++ code could be made secure with C++14 and tons of warnings?

<comment><USER79> Is that a no?

</comment></comment></comment><comment><USER81> Very exciting! I've worked through the tutorial in the past and enjoyed Rust very much but since then have just been passively following progress on HN. Looking forward to actually building something with it now.

</comment><comment><USER82> Congratulations to everyone involved!! Exciting times!

</comment><comment><USER83> Congrats!

</comment><comment><USER40> \o/

</comment><comment><USER84> Congrats! This is awesome. Been waiting for 1.0 to really start digging into Rust. Now's the time :)

</comment><comment><USER85> Just today I looked at beta release , congratulations and looking forward to using Rust

</comment><comment><USER86> Can somebody explain for what kind of use cases would this be helpful to use?

<comment><USER13> Any time 'it matters'.

There's lots of stuff that we build, and we say things like, "Language X is slow, but it doesn't matter." "Language Y uses a lot of memory, but it doesn't matter." This is very, very often true. But every once in a while, it really matters.

That's when you want something like Rust. When the details are important. When you need full control, but you'd like a compiler to help catch your mistakes. When a garbage collector has too much overhead. When you need to write something inside of Language X or Y, instead of a C extension, you can use Rust.

Basically, anywhere you'd use C or C++, Rust is a great fit. Elsewhere? Maybe, maybe not. Depends.

<comment><USER87> > When you need to write something inside of Language X or Y, instead of a C > extension, you can use Rust.

Are there any examples/discussion/information for interacting with rust from python, like you would a C extension?

<comment><USER13> I devoted a whole chapter of the book to Ruby/Python/node embedding: [http://doc.rust-lang.org/book/rust-inside-other- languages.ht...](http://doc.rust-lang.org/book/rust-inside-other- languages.html)

A Ruby gem in Rust was one of our earliest production uses.

</comment></comment></comment></comment><comment><USER88> Anyone succesfull getting any glfw stuff on windows to build dependebly yet?

</comment><comment><USER89> Super!

</comment><comment><USER90> Great job. I look forward to coding something over the weekend!

</comment><comment><USER91> Congratulations to the Rust team. I have been waiting for this.

</comment><comment><USER92> +1, Congratulations Rust Team :)

</comment><comment><USER93> Congratulations!

</comment><comment><USER94> Awesome!

</comment><comment><USER95> cheers LOL</comment>


PowerShell: condemned to reinvent - <AUTHOR> http://blog.brandonbloom.name/2009/04/powershell-condemned-to-reinvent.html

<comment><USER2> There was a project, I think back in the late 90s, with the goal of adding XML output and parsing options/ability to many of the UNIX command line utilities to do more robust things than is possible with flat text. I can't find it right now though.</comment>