The Rust community's crate host - <AUTHOR> https://crates.io/ <comment><USER2> Here is the most important part to me:

"Take care when publishing a crate, because a publish is permanent. The version can never be overwritten, and the code cannot be deleted. There is no limit to the number of versions which can be published, however."

That. Is. Awesome.

<comment><USER3> This has been true of CPAN for a long time, and comes as a result of it being a network of FTP mirrors. I don't know when people decided it was a good idea to be able to yank a package (for example, from rubygems). It just complicates the whole setup and makes it less flexible.

<comment><AUTHOR> I can speak to the Rubygems case: you'd be surprised at how often people publish proprietary/private information, and then need to pull it down. It happens often enough to actually be a burden on the Rubygems team (at least, when I used to co-work with one of them) that they left 'yank' in.

<comment><USER4> > you'd be surprised at how often people publish proprietary/private > information, and then need to pull it down.

But once published, isn't such information already compromised for all practical purposes ?

I can understand the legal reason behind "pulling it down" (using someone else's IP, etc), but practically speaking the private information once published cannot really be "undone" (at best you can make it hard to find, and disassociate from yourself).

<comment><USER5> Let's say you accidentally published your name, address, and social security number.

If it is only up for 1 hour, the chances that anyone malicious sees it is low.

If it is there forever, the chances that someone malicious eventually sees it approaches 100%.

</comment></comment></comment></comment></comment><comment><USER6> Can anyone explain the following trend to me? I've been seeing it alot lately: On the install page [0] the installation instructions tell people to run this command: curl [https://static.rust-lang.org/rustup.sh](https://static.rust- lang.org/rustup.sh) | sudo bash This seems to me to be an extremely bad idea. Why would I want to pipe arbitrary commands into my shell? Even worse, the shell has to run with root priveleges? Does anyone actually do this? Am I overthinking it?

Of course, I can verify the contents of the script, but I still don't know that the script I've verified on their website is the script that's being run in my shell. Is it OK because the script is hosted over https, and therefore can't be modified on transmission?

[0][https://crates.io/install](https://crates.io/install)

<comment><USER7> Does curl return a partial output if a connection dies?

What if it dies and the last thing it got was "rm - fr /" but not the rest after the / ?

<comment><USER8> Never thought about this, interesting question.

You can try this equivalent, killing the server when it tells you to - [https://gist.github.com/aidanhs/e40417381e9aecb87b35](https://gist.github.com/aidanhs/e40417381e9aecb87b35). It prints '/', i.e. would remove your root directory if it was an `rm` command.

Won't be doing that again then.

<comment><AUTHOR> Remember that these days, with GNU rm, you have to pass in `--no-preserve- root` to actually `rm -rf /`. Attempting to remove something in the home directory and getting a `rm -rf /home/username/` would still be pretty bad.

</comment></comment></comment></comment><comment><USER9> Announcement and details are here: [http://blog.rust- lang.org/2014/11/20/Cargo.html](http://blog.rust- lang.org/2014/11/20/Cargo.html)

</comment><comment><USER10> I'm a bit disappointed that this whole site works only with JavaScript enabled. No graceful degrading or anything. With disabled JavaScript, the page is just empty.

</comment><comment><USER11> I was happy to discover that the backend is written in Rust as well. Here's the code for anyone who's curious: [https://github.com/rust- lang/crates.io/tree/master/src](https://github.com/rust- lang/crates.io/tree/master/src)

<comment><USER12> At first I saw that ember-cli was being used and wondered if the backend was done in JS. I came to the same realization as you.

</comment></comment><comment><USER13> Great work. Only one improvement I would like to see 1) Switch the web design away from javascript (at least for loading) or, 2) Implement some command line interface in cargo for searching crates and displaying it's description.

<comment><AUTHOR> Command-line search would be cool, for sure. Submitted! [https://github.com/rust-lang/cargo/issues/925](https://github.com/rust- lang/cargo/issues/925)

<comment><USER14> What about requiring JavaScript even for the bare minimum of functionality? (That is, even loading the main page.)

<comment><AUTHOR> I would agree with adding some <noscript> tags to at least print a message telling you to turn it back on, sure. Filed: [https://github.com/rust- lang/cargo/issues/931](https://github.com/rust-lang/cargo/issues/931)

</comment></comment></comment></comment><comment><USER15> Am I correct in assuming that this is focused only on source distributions right now?

<comment><AUTHOR> That's correct. Rust doesn't have a stable ABI, so you'd have to have the same exact compiler revision as the one it was built with for it to work. And that's just the first issue...

</comment></comment><comment><USER16> It's very impressive. I am concerned that it requires enabling scripts from google.com to even show any content. Mozilla has shown it actually cares about user privacy so I hope they address it.

<comment><AUTHOR> I already spoke with someone who is sending a PR to fix this, so hopefully that will not be true soon.

<comment><USER16> That's great. To be honest I really didn't expect a response for such a pedantic complaint. Most people accept a world where Google touches everything with its JavaScript and font CDNs etc. The site looks great and I'm really enjoying working my way through the Rust Guide at the moment.

<comment><AUTHOR> I am, uh, very excited for this launch. :) (and glad you're liking the Guide too, please open issues if it can be improved)

</comment></comment></comment></comment><comment><USER17> For me the ability to use packages made by other people is a draw card for a language.

However, when I first went to the site, all I could think was "Whats a crate in relation to programming or more specifically Rust? Is it Rust's idea of a package (eg like ruby gems)."

I just think it would be good to have the site say Cargo: The Rust language package manager.

The site also says this:

"The Rust community's crate host". Is it not a cargo host for distribution of crates where crates are Rust packages? Is there non-community crate hosts?

<comment><AUTHOR> Basically, crates are packages, yes. It might be good to add some non-jargon-y copy there too, yeah. :)

</comment></comment><comment><USER18> If you aren't cool with me using your code, I respect that. I don't like forcing people to give up anything including their rights to their own repo.

I just don't feel comfortable working on someone's code if they aren't willingly consenting to it. just not cool at all! Human consent is just not a permanent thing.

Besides if the file disappears from the remote source, you can still build for the time being. It's not the end of your project, but it may be the end of someone else's career - you never know what reasons people had. Just respect peoples rights over their data.

The constant argument, "it's already on the internet" doesn't absolve any of us, from respecting peoples reservations. And if it's "already on the internet" then you can trust that someone will illegally copy and repost the repo on-line but where does that leave us ethically?

not the way I roll.

<comment><USER19> That seems like a very extreme view of intellectual property. "Intellectual property rights should be so strong that you can retroactively censor data you made freely available."

<comment><USER20> The Right To Have My Work Forgotten. Yeah, I don't think Right To Be Forgotten makes any sense either.

</comment></comment></comment><comment><USER21> I'm really looking forward to publishing some early crates! A cargo search from the terminal would be ace as well.

<comment><AUTHOR> You're going to want to subscribe to [https://github.com/rust- lang/cargo/issues/925](https://github.com/rust-lang/cargo/issues/925) then :)

</comment></comment><comment><USER22> Second most downloaded: brainfuck_macros

<comment><USER23> _A compiler plugin that converts brainfuck code into Rust at compile time, letting your BF programs be optimised by LLVM to super-fast native code._

</comment></comment><comment><USER24> Hooray! This has been eagerly awaited in the rust community for a while. Thanks, Steve!

<comment><AUTHOR> Basically zero of the thanks should go to me. Alex Crichton has been hard at work on this for the past while, both Cargo itself as well as the site.

<comment><USER24> Ah, then: Thanks, Alex!

But fortunately "thanks" aren't zero-sum, so I'll leave your ill-gotten gains alone. :p

</comment></comment></comment><comment><USER25> I'd love to see categories added to crates.io kind of like ruby-toolbox.com. Categories as well as repository activity information is helpful for discovering libraries that will suit your needs. Since there are so many ruby gems, it is now hard to properly categorize gems, and ruby-toolbox doesn't do the best job of this anymore. I found it to be very helpful years ago. Ruby- toolbox is still helpful in that it can show some similar projects and show project activity to help you see which projects have more momentum.

<comment><AUTHOR> If you look at each project's page, for example, [https://crates.io/crates/gl_generator](https://crates.io/crates/gl_generator) was the first when I loaded up crates.io, on the right there's a "Keywords" section.

<comment><USER25> Fantastic. Not sure how I missed that.

Edit: There are plenty of crates not categorized, and that must be how I didn't see this feature.

</comment></comment></comment><comment><USER26> But how does one avoid having crates.io being flooded by bad/useless crates?

And couldn't the same crates end up occupying all the "good" crate names?

<comment><AUTHOR> In theory, this could happen. In practice, Ruby/Python/JavaScript seem to be doing just fine.

<comment><USER27> Have you guys given any thought to namespacing packages by developer, like Github. I've had to rename a couple of my own Python packages before uploading them to the package index to avoid naming collisions, so it definitely becomes an issue once the repository hits a certain critical mass.

I assume Rust will be around for a while (I certainly hope so - I've just started learning it!) so it might be wise to plan for growth now before it's too late to implement.

<comment><AUTHOR> It creates a significant amount of complication. When I'm writing a blog post or documentation or in conversation, how do I differentiate between your foo and my foo? When I 'extern crate foo' in my source, which foo should it use?

While it's true that sometimes collisions happen, in practice, you just choose a new name. Everything is significantly simpler, which in software is very often a Good Thing.

<comment><USER27> I can appreciate that it adds complication to the implementation. I don't think identifying a particular crate would be an issue though, any more than identifying a particular repository on Github is. It's easy enough to talk about jdoe/foo if there's any danger of ambiguity, and links are definitive by their nature.

Just from my own experience, I know that it makes me less likely to make packages public if I have to give them odd, collision-avoiding names first - especially as I then have to use those names myself. It's particularly annoying when the incumbent package is 10 lines of poorly-written abandonware that hasn't been touched in years, which often seems to be the case.

I know this isn't an issue for Rust now but I'm thinking about ten years down the road when you have 250,000 crates on the site, 99.9% of them junk, clogging up that flat namespace. (Python's repository has more than 50,000 packages and seems to be growing at an accelerating rate now that it finally ships with a decent package installer by default.)

<comment><AUTHOR> > I don't think identifying a particular crate would be an issue though, any > more than identifying a particular repository on Github is.

Nothing is impossible, of course, but the language already has a flat crate namespace. So you could either implement some kind of layer on top of that, or change the language itself to have some sort of crate hierarchy somehow. All just to have two crates named 'http' rather than one named 'http' and one named 'requests' (for example.)

Here's another way of looking at it: shipping a flat namespace is a proven, well-worn solution. Adding in a hierarchical one, on top of the language, which has a flat one, provides dubious benefit, for significant implementation complexity.

<comment><USER27> Meh, if I wanted a 'proven, well-worn solution' I'd use C++. I want you guys to sprinkle fairy dust on my code and make the experience magical ;)

Seriously, I do get that there are trade-offs. I'm just interested in how you've been weighing up the alternatives as I do often find myself wishing that other projects I've been involved in had taken the hierarchical approach at the beginning when it was an option.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Does cargo support alternative package repositories? For example, at $EMPLOYER we have a DevPI[1] installation, so company-internal packages can be shared between employees as easily as public packages can be shared with the Internet at large.

[1]: [http://doc.devpi.net/latest/](http://doc.devpi.net/latest/)

<comment><AUTHOR> Yes, you could grab all this code off of GitHub, spin up your own instance, and then set up your `.cargo/config` file to point at your copy, and it Just Works.

<comment><USER29> I really wish it would also allow `~/.config/cargo/config` just like `~/.config/git/config`.

<comment><AUTHOR> I believe there is an open ticket to follow the XDEG specification or whatever. You may want to find and :+1: that.

</comment></comment></comment></comment><comment><USER18> This will certainly make our lives easier.

BUT.

1) Why store a package, wouldn't an index rather than another repository be more efficient and flexible.

Cargo already has the capability to get packages from git urls...

I had some other nicks but I see this is on github so I'll try and contribute there.

I like the site, and can't wait to test it out. Thanks to all who have been working hard on this!

<comment><USER30> > 1) Why store a package, wouldn't an index rather than another repository be > more efficient and flexible.

I suppose the authors experienced the "guy deleted his Github repo" effect one time too many. It's a very sensible decision. Getting packages for git urls is fine when you're hacking something together, but there is absolutely no way I'd put anything in production relying on something that fragile.

<comment><USER18> I think it's even worse depending on a repo whose author refuses to or is unwilling to maintain.

Besides git is hardly fragile especially if we are talking github. I happily clone and pull projects all the time without a single hitch. Also if you think about it github/attlassian are all dedicated to task with datacenters around the globe, while for the rust team the repo _might_ be somewhat of a side gig.

<comment><USER30> I'm not so worried about Github going down as I am about people removing their repos.

And why do you think depending on a repo is worse than depending on Github? If the package is not maintained anymore, license willing, you can always fork it and bump the dependencies yourself, even if, in the worst of cases, you need to keep the fork local. However, if it turns out you have to maintain a lot of third-party libraries yourself, it's a sign either of a bad ecosystem, or that you picked the wrong libraries.

<comment><USER18> I guess at the end of the day so long as cargo has the git option people like me will always get our code fresh from the source, with the maintainers consent. It's not like I'm being forced to use the crates-repo.

Let's agree on one thing we shouldn't be maintaining other peoples abandoned/illegal libs, however thanks to them being posted on the crates-repo permanently, we'll continuously keep running into them...

<comment><USER30> > Let's agree on one thing we shouldn't be maintaining other peoples > abandoned/illegal libs, however thanks to them being posted on the crates- > repo permanently, we'll continuously keep running into them...

Maybe. But at least, if you pick your or somebody else's unmaintained code from five years ago, you have a fighting chance of making it compile and run.

</comment></comment></comment></comment></comment></comment><comment><USER31> Maybe it's just the very beginning but I would really like to see detailed descriptions for every crate as well as links to the website or repository if available. It's just hard to understand what they do, how they do it and their quality.

<comment><AUTHOR> Yesterday, we implemented a warning if your description and/or license aren't filled in when you upload a package. And 'homepage' is also possible too, authors just have to put them in.

<comment><USER32> small nitpick: 'homepage', not 'website'

<comment><AUTHOR> whoops, edited, thanks

</comment></comment></comment></comment><comment><USER33> Cool. It would be nice if there was a link to each package's web site or source code.

<comment><AUTHOR> If authors give us that metadata, it appears on the site.

</comment></comment><comment><USER34> FWIW, the page is a bit messed up in IE11 on Windows Phone: [http://1drv.ms/14VI93Z](http://1drv.ms/14VI93Z)

Awesome work!

<comment><AUTHOR> Filed! [https://github.com/rust- lang/crates.io/issues/56](https://github.com/rust-lang/crates.io/issues/56)

</comment></comment><comment><USER35> Sweet, let's build an OS based on Rust code now!

Why don't we port something that's already got an eye for security, like Minix?

<comment><AUTHOR> There's already a few projects doing so. Drop by #rust-osdev on Mozilla's IRC network sometime. :)

</comment></comment><comment><USER36> Why is cargo not bundled with my rust install?

<comment><USER37> rustup.sh installs both.

For other install methods see: [https://github.com/rust- lang/rust/issues/16456](https://github.com/rust-lang/rust/issues/16456)

</comment></comment><comment><USER32> Congrats on shipping, cargo team!</comment>


Ask HN: Is there ANY scientific evidence of 5G being harmful - <AUTHOR> I see lots of people talking about negative health effects from 5G but I have never seen any evidence. It is always some guy talking on YouTube or equivalent. If there is any actual evidence, I would like to see it. It looks like conspiracy theory to me but I haven't done enough personal research to pass judgement. <comment><USER2> Wackiness aside, there is some evidence that some wireless technologies can and do present real dangers (e.g., a Scandanavian study a few years back that showed pelvic blade bone density was as much as 30% less on the side men carried their GSM phones on their belts.)

5G is also a horribly imprecise term - it can include anything from 600 MHz UHF to 40 GHz mm wave, and widely varying modulation and power control schemes. The lower bands are probably not a problem, as we've been using some of them for quite a while, though not on our persons. The mm-wave and THz stuff really is a huge unknown.

One problem is that these technologies don't ever get seriously tested for biological effects: They just get deployed due to industry/govt/carrier/market pressure, and by the time we have enough data to even know therer might be a danger (viz, the GSM study above), we're already experimenting on the population as test subjects for the next generation of risk. At least as much as the frequency, the modulation method seems to matter, too, with the very sharp-edged full-power square waves of TSM/GSM type signals probably being considerably worse than the noise-like CDMA, for instance. (IMO, there is probably no current (4G/5G) LTE technology that is nearly as safe as CDMA.) More recent research does seem to show that there are RF health effects that are NOT related to heating, but heating is the only thing any of the gov't/industry "RF safety" regs cover.

This really is one of those areas where an honest person is forced to recognize that we have no idea what we don't know. RF and biology is a barely studied field, yet we know that many (most? all?) living things do have biophoton systems that we don't understand, and have largely ignored. 5G could be heinously dangerous, or relatively benign. So the answer to your question is no, there isn't (much) solid evidence yet that 5G is dangerous, and we won't really know for many years. But neither is there any actual evidence that it is safe and harmless...

<comment><USER3> I think the modulations schemes are largely the same across the board for 5G. Also 4G LTE and 5G signal waveforms both look a lot like CDMA.

</comment></comment><comment><USER4> No.

There's questions about the general increase of wireless traffic in general, but nothing has be proven at all since cell phones came about. Let alone microwaves, or household appliances. At least not to my knowledge.

<comment><USER4> Also, one of the conspiracy theories against 5g is that the towers are literally sucking the air out of your lungs. :-|

[https://www.theverge.com/2020/4/4/21207927/5g-towers- burning...](https://www.theverge.com/2020/4/4/21207927/5g-towers-burning-uk- coronavirus-conspiracy-theory-link)

<comment><USER5> True, that one is a little wild but there is also another angle as to why 5g is "bad": [https://news.ycombinator.com/item?id=22480444](https://news.ycombinator.com/item?id=22480444)

</comment></comment></comment><comment><USER6> Not a scientific study, but a notable anecdote that struck me a while ago. Firefighters in SF reported a host of symptoms after a 5G unit was placed on their station: [https://sanfrancisco.cbslocal.com/2018/01/25/consumerwatch-5...](https://sanfrancisco.cbslocal.com/2018/01/25/consumerwatch-5g-cellphone- towers-signal-renewed-concerns-over-impacts-on-health/)

</comment><comment> tangent-man This page seems to have a fair few links to legit scientific studies on the dangers of 5G and related technologies.

[https://ehtrust.org/science/cell-towers-and-cell- antennae/co...](https://ehtrust.org/science/cell-towers-and-cell- antennae/compilation-of-research-studies-on-cell-tower-radiation-and-health/)

I don't think it's a simple matter of: non-ionizing radiotion=safe.

</comment><comment><USER7> there are some interesting links in this HN comment regarding this question:

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

in general, research on RF radiation can take time to wade through and you might not arrive at a satisfying answer one way or the other.

<comment><USER2> Hadn't seen some of the links in that post - definitely some good solid info there...

</comment></comment><comment><USER8> Pro-tip: this happened when EDGE, 3G, and 4G were released and in all of the above cases, were debunked.

<comment><USER9> [https://www.chicagotribune.com/investigations/ct-cell- phone-...](https://www.chicagotribune.com/investigations/ct-cell-phone- radiation-testing-20190821-72qgu4nzlfda5kyuhteiieh4da-story.html)

Not so sure they were. The testing wasn't exactly great and compliance in the real world is... less than realistic.

</comment></comment><comment> tangent-man In my opinion your better off asking this question on a biomedical forum as Computer Programmers and Electronics Engineers seem to have a conflict of interest regarding this for some reason.

</comment><comment><USER10> Yes [https://www.europarl.europa.eu/RegData/etudes/BRIE/2020/6461...](https://www.europarl.europa.eu/RegData/etudes/BRIE/2020/646172/EPRS_BRI\(2020\)646172_EN.pdf)

<comment><USER11> Millimeter waves (30-100GHz range) attenuate like crazy & are seriously degraded by pretty much everything (eg: rain, dust).

For folks who must fret over mm wave tech, it's worth considering that cell towers have been using 11-83GHz bands for short distance backhaul & linkage for decades. So have tons of other industries.

Last, I'm about positive that only some approved frequency groups in the 5G standard will be in use, in any given region. Lower bands should see the widest deployment.

</comment></comment><comment><USER12> no but we also need evidence that it's useful

<comment><USER13> I'd agree with that. I keep seeing headlines like "5g will enable the IoT" and "5g will take AI to the next level" but I have yet to see what specifically about 5g makes that claim any more true than 4g or 3g or EDGE. We haven't even gotten the full speed we were promised with 4g.

</comment></comment><comment><USER14> Not that I've seen.

</comment><comment><USER15> no

</comment><comment><USER16> The science-based answer is that it depends on the frequency and effect on human tissue.

So mounting a telco transmitter on your roof is probably bad for you, similar to being inside a microwave oven.

Holding it pressed against your ear while talking is also probably bad for you depending on duration, but mfgs. do tests at various distances from your ear.

If you're a real estate agent using your mobile phone all day, I'd use an earpiece and put the phone on your desk away from your body.</comment>


Royal Caribbean's payment vendor Wirecard reports $2.1B in cash is missing - <AUTHOR> https://www.miamiherald.com/news/business/tourism-cruises/article243645002.html <comment><USER2> This looks like another stone into RCI. Wirecard processes payments for a multitude of companies including RCI and most likely remittances for most of them are under huge question, but for some reason accent was made on RCI.

<comment><AUTHOR> I think the RCI angle was just of particular interest to the Miami Herald given how many cruise ships come through Florida.

<comment><USER3> Miami is RCIs headquarters, lots of staff there.</comment></comment></comment>


CoverHound Lands $4.5M To Become The Kayak Of Online Insurance - <AUTHOR> http://techcrunch.com/2013/02/07/coverhound-lands-4-5m-from-rre-bullpen-blumberg-to-become-the-kayak-of-online-insurance/

<comment><USER2> Not knowing who Kayak are makes this headline especially interesting. What does it mean to be a kayak of online insurance? Are CoverHound able to right themselves if they capsize? Are they slow and hard to paddle?

<comment><USER3> <http://en.wikipedia.org/wiki/Kayak.com></comment></comment>


Can We Just Cut to Infrastructure-as-Declarative-Code? - <AUTHOR> https://medium.com/@archisgore/can-we-just-cut-to-infrastructure-as-declarative-code-3b0b44fa02 <comment><USER2> I really like k8s itself and I think these yaml files are a great API layer, but the way people produce these files nowadays (templating systems and a lot of glue like helm) is a joke and in a real, even mildy complex environment becomes a terrible mess really quickly. What I really want is a typed programming language, where using normal code we describe how to produce all these yaml-described k8s resources using whatever abstractions make sense in our business.

Twitter thread I had about it a while ago: [https://twitter.com/dpc_pw/status/1182022825361625088](https://twitter.com/dpc_pw/status/1182022825361625088)

<comment><USER3> > What I really want is a typed programming language, where using normal code > we describe how to produce all these yaml-described k8s resources using > whatever abstractions make sense in our business.

This is more or less exactly what we're working on at Pulumi. Using a language like TypeScript to describe Kubernetes infrastructure provides a nice mix of simple JSON-like resource definition, strong typing, and the ability to use variables, loops, functions, classes, packages, test frameworks, and more from an expressive general purpose programming language. You still have access to the full fidelity of the raw Kubernetes API, but also all the tools you need to apply proper software engineering on top of it.

[https://www.pulumi.com/kubernetes/](https://www.pulumi.com/kubernetes/)

<comment><USER4> Huh, why build an entirely proprietary language for this? There are existing toolchains that bend existing rich configuration languages, like Nix [0] or Dhall [1], to produce Kubernetes object definitions. In this way, not only can existing libraries be leveraged, but no new semantics have to be learned, and no third party needs their palms crossed.

This had to be pointed out; Pulumi's docs repeat the adjective "real", as if its competitors aren't real. "real code", "real package management" [2], "real languages" [3], "real programming model" [4]... Nix and Dhall are quite real, though. So is this an incomplete survey, or are Pulumi's docs unrealistically self-aggrandizing? TBH even just this one paragraph of yours is pretty tough to stomach, as if loops and functions in a configuration language were a novel concept.

[0] [https://github.com/xtruder/kubenix](https://github.com/xtruder/kubenix)

[1] [https://github.com/dhall-lang/dhall-kubernetes](https://github.com/dhall- lang/dhall-kubernetes)

[2] [https://www.pulumi.com/docs/intro/vs/k8s_yaml_dsls/](https://www.pulumi.com/docs/intro/vs/k8s_yaml_dsls/)

[3] [https://www.pulumi.com/docs/intro/vs/chef_puppet_etc/](https://www.pulumi.com/docs/intro/vs/chef_puppet_etc/)

[4] [https://www.pulumi.com/docs/intro/vs/custom/](https://www.pulumi.com/docs/intro/vs/custom/)

<comment><USER5> I would imagine that a "real programming language" here means not only any Turing-complete language but also a language that has been consistently at the top 10 most popular programming languages in the world for a while (which javascript is, and typescript is its superset).

<comment><USER4> I would hope that we can do better than that. Both Nix and Dhall are designed for readability in the limited niche of configuration management, and their authors considered that design choice to be important enough _on its own_ to merit a new language. Dhall is explicitly _not_ Turing-complete.

</comment></comment></comment></comment></comment><comment> joatmon-snoo > "A System with 1000+ Microservices at Planet Scale described As Code 100% > Declaratively"

There's a fundamental problem here that I don't believe a (taking Pulumi at face value) better config language solves: you are working with an inherently complex system, and configs are only one part of that complexity.

Doesn't matter if you have 1k+ microservices, a monolith with 1k+ RPC services, or something in between - at that scale, you have accumulated such complexity in the system that configs are just one facet of the problem.

I do think it's an interesting premise (but I wonder if they've thought about the zip bomb problem, which has persisted across many, many new technologies, including yaml - at some level, you want to try to make guarantees about config parsing runtime requirements - cpu, memory, disk). An idea that's bounced around my head before is letting folks define small programs - Java, Python, whatever - to generate configs, and use static analysis to encourage hermeticity/reproducibility/etc (e.g. disallow random, disallow concurrency, no envvar deps).

A similar, but related problem: people very frequently write configs such that you could change settings x, y, z using this one line, often for the sake of comprehensibility/readability. But we have no way of writing tests for this- all you can do is hope whoever does the code review keeps that in mind.

</comment><comment><USER6> I'm still waiting for mainstream adoption/normalisation of workstation setup config as code.

ansible & friends fell well short.

biggest peeve is vscode allows you to programmatically install extensions yet firefox doesn't.

something something nixos but i'd like that for fedora/ubuntu etc.

<comment><USER7> Isn't that what Chef for?

</comment></comment><comment><USER8> I still think what made Docker popular where other tools failed was its very watered down imperative style. I was always a little surprised that swarm and other tools for orchestrating containers look absolutely nothing like a dockerfile.

<comment><USER9> I suppose if you push things to the extreme, there are two ways to do it:

1) Prolog/constraint logic programming.

2) Macro recording and code/config generation.

Both have their upsides and downside. Our current Unix configuration model isn't designed for transparent event-sourcing style which macro recorders require. Even Windows with its Registry is half-baked at best. A lot of side effects are not deterministic. What happens if you try to implement Excel- style macro recording is that you end up with a lot of broken generated code due to missing knowledge or specific side effects that can't be reliably triggered. This requires an AGI to solve.

On the other hand, using Prolog works for high level, very specific stuff like firewall configs. But just like automated proof solvers such as Coq, Lean, you need a strong "standard library" of working configs and bindings to get started otherwise you will be starting from scratch everytime. This is a weakness that's going to be difficult to overcome. There aren't many companies doing developer tooling and integrations that are successful, HashiCorp and Jetbrains being the exception, not the norm. Docker may be an unicorn on paper but it still struggles to turn a profit.

Both of the above methods can be successful if a major corporation is willing to throw money at it. Otherwise we will be stuck with whatever software FAANG decides to release because the developer tooling industry is quite cruel to smaller players. Flynn, Deis etc. Behind every Heroku lies countless dead startups.

</comment></comment><comment><USER10> Yes, but the language has to be APL, with comments in Esperanto.

Even is you make infrastrcture coding as simple as SQL DDL, you have still said naught of the specific application's schema/design.

Once you are past a dirt-simple, low-traffic LAMP app, I'd expect all bets are off.

</comment><comment><USER11> This is a great article that expresses a similar desire for a "real" programming language as an article I wrote here: [https://adaptjs.org/blog/2019/09/25/react-for- infrastructure](https://adaptjs.org/blog/2019/09/25/react-for-infrastructure)

I think the real problem we have with infrastructure is one of evolution, abstractions and leaky abstractions.

First, infrastructure is not a static thing, it changes over time in response to code updates, environmental load (autoscaling), etc. And the details here matter. How should new code be rolled out (blue/green, how fast, what are the quality metrics, etc.). What should happen to the old instances while the new stuff is rolling out? When should they be killed?

What we really need is a good way to declaratively specify what to do, and how the components in that declarative specification should evolve as new stuff is rolled in, load changes, etc. We need a good way to specify the control plane for our infrastructure. adaptjs (adaptjs.org) is our TypeScript-based open source project to provide this. It is still early stage, but I think it is pretty promising.

The second issue is one of abstraction. All these things are complex and often need customization to suit the particular application challenges. Using templates, CDK, Pulumi, or anything else to generate YAML is fine, but as the article points out, you have no insight into how your specification got realized into the low-level infrastructure.

Moreover, you have to care since you need to know the low-level implementation to debug, understand cost, analyze logs, etc. Adapt has some machinery so that you don't always need to understand the low-level implementation for this stuff, but since it is still early, that part of the system needs work before it is ready for prime time.

</comment><comment> yjftsjthsd-h Isn't Terraform declarative infrastructure as code?

<comment><USER9> It is, but it isn't very pleasant to use. It's the difference between Sublime Text and Notepad++. A curmudgeon software engineer may argue that the former is lipstick on a pig because the latter exists. But developer UX is important, the difficult part is getting them to pay for it (just google the amount of Sublime Text piracy posts on GitHub).

<comment><USER12> Would you like to expand on your view? I've used terraform a lot and never had any issues with the tooling. But then again it's just a pretty simple CLI/config setup? Do you mean you're looking for graphical interfaces to write config files?

<comment><USER13> Personally, HCL is what bothers me. Yes, it's infrastructure-as-code... but that code is in a niche proprietary language. It gets unpleasant as soon as you go beyond trivial static config.

Pulumi and AWS CDK are taking what I think is a better approach: use your favourite general-purpose language to build the declarative infrastructure definition.</comment></comment></comment></comment>


I opened a charming neighborhood coffee shop. Then it destroyed my life. - <AUTHOR> http://www.slate.com/id/2132576 <comment><USER2> Funny how the last line of the article says,

 _Looking back, we (incredibly) should have heeded the advice of bad-boy chef Anthony Bourdain, who wrote our epitaph in Kitchen Confidential: "The most dangerous species of owner ... is the one who gets into the business for love."_

This in spite of recent conversations here discussing "doing what you love": <http://news.ycombinator.com/item?id=449295>, <http://news.ycombinator.com/item?id=449457>

Why didn't doing it for love work for the author? I suppose if I were to answer the question myself, I'd say either a) they didn't love it _enough_. or b) They did some bad math.

Why not just sell the crossiants for $3? Why not sell the cold house coffee for $3 instead of $1? Raise the price, let your customers keep you alive. If they like what you have to offer, they will.

If their dream was to open a coffee shop, why /not/ work there full time? Why not make it work? Other coffee shops _have_ figured out the formula and _do_ survive. Maybe their owners loved it more?

Every business struggles in the beginning.

Do /not/ give up. Keep going. If your formula isn't working, tweak it. Don't close up shop. That's what you _don't_ do if you love what you do. You don't give up on something you love. You can't.

<comment><USER3> I think he loved the idea of owning a coffee shop, not actually doing it.

<comment><USER4> As I sit in my cubicle day in and day out practically forcing myself to do work that I don't really care about, I often wonder if I merely love the idea of being an engineer rather than the actual practice of it.

<comment><USER5> Yeah. It's kinda sad when you have a romantic idea of something, but reality paints a totally different picture.

I'm learning a new language at the moment. The romantic idea I had in my head was being able to speak it fluently with friends from that culture, read books, etc. The reality is that learning a language is difficult and and takes a lot of effort and patience.

Thankfully, I love studying it. But then if I didn't and then gave up I'd still be painting that romantic image in my head thinking i "shoulda, coulda, woulda..".

I kinda forgot where I was going with this... sorry :-(

<comment><USER6> With languages, my experience has usually been that it's easy and gratifying at first. Then it gets tough and demoralizing. And then you sort of break through that wall and it becomes quite gratifying again. So hang in there. :)

Oh, and to get past the level where you can hold a simple conversation I have found immersion necessary. My Hebrew improved as much in a month in Israel this past summer as it had in the previous year.

<comment><USER7> "I have found immersion necessary."

This is the only practical way to learn a language. There is an oft repeated cliche about playing quarterback in the NFL, that no matter how much you practice or try to simulate game conditions, the speed and chaos of actual game conditions is something you can't understand, really, until you experience it.

Well, learning a foreign language does not involve 300 pound men coming at you at high velocity, but the real experience of trying to communicate something you really want to say to a real human being is a very different experience than learning words or even grammar structure from a book, audio, video, or lecture. Even interacting with classmates is somewhat contrived, because you are probably trying to say something your teacher prepared for you, instead of getting own ideas across.

So, to summarize: learning a language with out immersion (or something close to it) will likely never amount to anything more than an academic experience.

<comment><USER6> Well, most of what you say is true, but doesn't require immersion. For example, I have Israeli friends here in the States, and I keep in touch with a couple cousins in Israel. So it's possible for me to have real conversations (as opposed to contrived conversations with classmates or workbook exercises etc.) without actually going to Israel.

I found immersion useful because when you hear a language all day, every day, it seems to seep into your subconscious. Also, I think that language learning is a function of density rather than just volume, so to speak. That is to say, spending ten hours speaking a language every day for a month is more effective than speaking it for half an hour a day for 600 days.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Maybe I'll do this later, but I always wanted to open up a hacker's place. I'd call it the Bit Bucket.

Part bookstore (~50 titles, classics only - W. Richard Stevens, etc.), part coffee shop, part decent hardware shop (FPGAs, GPGPU, blade servers, and half & full-height rackmounts you can convince your S.O. to let you put in the basement), and bar.

Also, a good selection of little parts that you'd normally have to ebay, a little selection of RAM, heat sinks, PCI cover plates, etc. I'd put it in a display where you'd normally see the baked goods.

I'd have no illusions of being profitable at this, but it'll give me something to do when I retire :-)

<comment><USER9> Sounds like a smaller version of the first Fry's Electronics: <http://en.wikipedia.org/wiki/Fry%27s_Electronics> They did OK.

<comment><USER10> Just be wary of employees that have a suite named after them at a Vegas hotel.

<comment><USER11> Is that a general reference or something specific to frys?

Could you elaborate more?

<comment><USER12> From the linked wiki:

"In 2008, Fry's vice president of merchandising and operations, Ausuf Umar Siddiqui, was charged by federal prosecutors in an illegal kick back scheme involving Fry's vendors. The alleged scheme was designed to defraud the company in order to cover Siddiqui's gambling expenses"

</comment></comment></comment></comment></comment><comment><USER13> This also answers my longest-standing question about cafes: Why are there so few fun ones?

San Francisco's Valencia Street (with its immediate offshoots) supports hundreds of interesting businesses. Many of them are cafes. Only two of those cafes are any good: Ritual Roasters, and Four Barrel. Four Barrel was founded last year by a disgruntled co-founder of Ritual.

While the rest of Valencia's cafes are grimy, poorly lit, deathly quiet, or all of the above, RR and FB are sunny, friendly, and _loud_. That noise is all the foot traffic (and some David Bowie). The people sitting in Ritual for five hours on a laptop aren't paying the (staggeringly high) rent. It's the constant in-and-out of to-go cups. Mercifully, Four Barrel has no wifi and thus a more talkative, flowing crowd.

Ironically, because RR and FB have coffee that makes people come and go quickly, they can afford to make a pleasant space for people who stick around. Their solution to cafe economics was to make their own high-markup product.

Of course there are other solutions. Cafe du Soleil in the Lower Haight offers an extensive sandwich menu and gets its baked goods as part of a chain of boutique cafes and restaurants called the Bay Bread Group, which also sells bread to bigger clients like the Ritz Carlton. For all I know, Soleil is riding on the profits of the Bay Bread Group as an indulgent loss leader.

But I suppose there's a lesson there for any startup with a boutique aspect: Make your own supplies, and you might have a business plan to support your dream. In a way, wasn't that the model for Reddit and Justin.tv?

<comment><USER14> Honestly I think it's a location thing. Valencia Street is a place where interesting businesses would exist..I've always been intrigued at the kind of businesses I see when I visit friends in the area.

From personal experience (I've been in the market for coffee shop businesses of all types in Los Angeles for a couple years - from family owned tiny mom and pop stores to franchises), it's all about the location unless you have a lot of hype and if you have both even better. Anyone can start a coffee shop and stock their display cases with local/well known bakeries and coffee providers, but you need all kinds of customers (both the people who occupy a table with only a $1 cup of coffee all day long and the people who rush in and out, both something you can't get if you are badly-situated) and not just a little something extra. The latter is typically a way to get people to come to your store rather than another close by, or a little perk for your customers so they'll return later.

Plus, there's always Starbucks and Coffee Bean and Peet's to deal with... _sigh_.

<comment><USER13> But like I said, there are plenty of awful cafes on Valencia. I guess I conflated financial success and coolness: Mission Creek, one block down Valencia from Ritual, seems to get along just fine but it's a terribly dull place to go. The coffee there is just like anyone else's; the food is mediocre; the atmosphere is deathly silent. They've taken prime real estate and turned it into an office for people with no office -- and not a fun one. It's literally no more social than sitting in your living room, and the coffee and food are on par with what you could make for yourself. And the entire city is full of these decrepit little places that can only afford to offer mediocrity, because better food wouldn't necessarily bring in profits, and cranking up the music might drive away the customers who buy the most product. In the midst of all these mediocrity machines, Ritual and Four Barrel stand out because of what they've done with the same opportunities.

Okay, they do have one big real estate advantage: they bought giant spaces with room for a roaster. But is there any other way a cafe could serve something special that still attracts the high-profit foot traffic that turns Ritual and Four Barrel into community centers? I'd like to hope so.

</comment></comment></comment><comment><USER15> I'm a writer. I go to coffee shops, sit there, and drink as little coffee as possible, staring into my little book while taking up a table and spraying a Cone of Introverted Quiet everywhere I turn. I am the bane of the regular coffee shop. But what if there were a shop that tailored their business model to me?

Instead of charging for food or drink, and then letting you have the space for free, how about switching the two? Charge _for the table_ by the hour (or with a monthly subscription), and then have free little snacks and drinks to go along with the seat. Limit customers to those with a creative/insightful streak (yes, get resumes), and disallow anyone from sitting alone or ignoring the people next to them for more than ten minutes. Perhaps even invite famously loquacious people to hang out there (in the exact same way as the regular patrons do.) Thus is born a sort of "idea club"--like TED, but every day, and peer-to-peer instead of multicast.

On the same vein, don't buy newspapers (or anything else topical) for reading material; buy hardcover books, fiction and non-. Require that people read them out loud if they're reading (thus, basically, giving a reading of the book to whoever's nearby.) Don't have a wi-fi connection; _do_ have a "room librarian" that will look up the answers to questions on a hard line, and is ready to explain the answers in detail. And so on.

<comment><USER14> Writing this for the second time this week on HN...I should just copy and paste ;)

Coffee shops: expensive rent for owner because of prime retail location, foodservice business (therefore more requirements with less space to work with).

Workspace/office rental: not so expensive rent for owner since it can be located anywhere there is commercial real estate, is not a foodservice business (less restrictions, more space). Bonus: not as much noise and more actual office space with wifi and ethernet and places to plug in. Additional bonus for you: some of these workspaces will have newspapers and other reading material for you to check out without having to buy.

Both: offer tables and coffee and food for people who want to sit down and chill.

What a lot of people SHOULD be doing is going to a workspace (i.e. in los angeles there's theOffice and Blankspaces off the top of my head) and actually paying per table or workspace by the hour/day instead of sitting at a coffee shop where that per table pricing model is completely infeasible because of what a coffee shop inherently _is_. Sadly demand for them isn't as high as I would have thought, but the problem has been approached before in a way that doesn't bankrupt the owner (aka a coffee shop with an hourly per-table/seat charge).

<comment><USER16> What about an automated coffee shop? A machine that remakes coffee when it gets low with a reserve of beans it grinds automatically, dispensed in different sizes by coin or bill. Have a machine on the inside and on the outside, facing the street. So you can have your romantic atmosphere and make a lot of money selling coffee quickly to people on the go for the mere cost of a machine.

<comment><USER14> But there is only so much space for romantic atmosphere inside a shop (the main issue, really), and existing automated coffee machines are..limited (then again, most people would probably just get ordinary coffee). On the other hand, that sounds like an interesting thing to hack together for home if only I wasn't in love with my french press :)

Also when a similar topic came up last week, there was mention of charging a fee (i.e. $20/day) for use of the table, wifi and a bottomless cup of coffee.

It would be interesting to see both of these implemented in an actual coffee shop, cause they're not necessarily something I have seen and are certainly one way to approach the problem.

</comment></comment></comment></comment><comment><USER17> "There are wealthy gentlemen in England who drive four-horse passenger-coaches twenty or thirty miles on a daily line, in the summer, because the privilege costs them considerable money; but if they were offered wages for the service, that would turn it into work and then they would resign." --- Mark Twain

</comment><comment><USER18> As someone who opened a similar business I thought that the ratios that were listed as rules of thumb were failry on target with my experience, but the statement "If you haven't hit the latter mark in a month, close" was crazy.

1.) Your potential customers are creatures of habit and it takes time to change their traffic patterns. Your grand opening is your biggest splash and a key time to get attention, but getting return customers is a struggle to reshape their patterns.

2.) A new business should ideally be properly capitalized to slug out way more than a month. Not only does it take time to get people in the door but it takes you and your staff more than a month to adjust to the unexpected, get your act together, and polish your product.

If your new business is going to be your only stream of income you need capital available before going in to stretch more than a month. This piece of planning is every bit as important as the name on your shingle.

Opening a new and not yet profitable business does suck up your whole life, but if you succeed that doesn't have to last forever. Its after this initial "slugging it out" time period that you can reclaim your life.

</comment><comment><USER19> I think these people lacked business sense.

You are not selling coffee, you are selling an experience. Most people go to Starbucks for the experience they have there, the illusion of being refined members of society who can afford it. To feel cool among their peers. The coffee is an admission price. People with a laptop bothering you? How about providing a wi-fi service and charging for it instead?

To distinguish yourself you want to have outrageous quality and markups. You want to target upper middle class people who don't mind spending $10 for a large cup of coffee and a couple of baked goods.

Make your environment as nice as possible. Make the quality of your coffee as good as it can be. Be remarkable. Be well known for having the best coffee in your city, state, or even America. Make people want to drive 20 miles just to get there.

Just opening another unremarkable little coffee shop doesn't make much sense. Opening the "Fat Duck" of coffee shops does.

<comment><USER20> People go to Starbucks because once you've learnt Starbuckish you can order your coffee exactly how you like it anywhere. They're selling ubiquity. It's the same business as Subway, you can get your "unique" thing wherever you are. Brands that (successfully) go for "cool" you see people wearing their logo on their clothing and accessories and I don't recall seeing anyone who wasn't staff ever sporting a Starbucks logo.

My regular Starbucks, where they know me and start making my drink as soon as I walk in, I go to because it's on my way home from work and it's open 24 hours. And Starbucks knew that there was this kind of consumer and that's why they're there. That's what they're selling.

</comment></comment><comment><USER21> It is always easier to armchair quarterback people's stories like this, but I do see two problems that immediately stuck out at me.

Success in business centers around execution and if you do not execute effectively you are bound to fail. In the first paragraph the guy says "The one that, as you calmly and correctly observed, was doomed from its inception because it was too precious and too offbeat?" As a business owner if my customers were telling me I was "doomed" I would be working to change that perception. If a potential long-term customer sees your business as doomed from the start, he or she is probably going to resist going to your business by instinct. This can be especially true in the restaurant business and even more so with coffee shops. People are creatures of habit and tend to go places they like and enjoy. If you want people to come to your coffee shop it is going to take time (more than a month). If they do stop in and feel as if your business is doomed then what incentive do they have to come back again?

The second problem I see here is this guy had a dream and in that dream there was a part where he would open the shop and there would be immediate success. Not success earned by time and through customer loyalty. He expected the success of opening the doors and having people rushing in. Starting a new business takes time and, as others have said, a savings available to handle the rough times and starting period. This is especially so with restaurants and probably more so with coffee houses. Expenses are going to be high between rent, payroll, and food expenses. If you can't afford to handle these without a single customer walking in the door for a month or two your chances of success are instantly diminished.

The final problem I see is this guy was not open to changing his pricing. His solution was to go with the cheaper product rather than raise his prices. It is a known fact that people will pay more for a better product, but they aren't going to pay the same for a cheaper product. I surely wouldn't buy a Kia at a BMW price.

While I feel sorry for this guy and at the same time give him credit for trying, I do not feel as if he put enough thought into the business, gave it enough time, and surely was not familiar with the management side of running a restaurant. Sadly he learned the hard way and now his life is destroyed.

</comment><comment><USER22> A new reference article for those who want to know the difference between a startup and a small business?

<comment><USER23> I'm wondering what you see the difference as? For me, every start-up is a small business (with various size visions), and every small business is a start-up.

Is it the size of the vision? (ie, a boutique cafe will only ever be small, while a start-up might be valued at $15B) Or is it the difference between leveraging effort rather than leveraging scalable code?

<comment><USER24> I was talking to Justin recently, and he gave the most succinct definition I've heard: A startup is a business aiming for a liquidity event.

Edit: Reading the responses to this, people clearly got the wrong idea. A liquidity event != early acquisition. But every successful startup nonetheless hits liquidity: acquisition, IPO, or substantial dividend payment to its shareholders. And that's a distinction between a successful startup and a successful small business, which are not intended to achieve liquidity.

<comment><USER25> That's a popular one, but I find it so depressing. Here you've quit your job and thrown yourself into something you believe in, and from the first day you're thinking about how you'll unload it?

<comment><USER26> I think the idea of startupism, or startup mentality, is that one believes most of all in _starting_ things - kicking off great ideas - rather than being a shopkeeper. There are _other_ people who like being shopkeepers. Let _them_ run it after you've created and tamed it for them, so you can be free to kick off other great ideas - or to help new entrepreneurs do it.

</comment></comment></comment></comment></comment><comment><USER27> I tried to open a neigborhood grociery store. It didn't destroy my life, but I did lose a lot of respect for the local city officials. Imagine if you wanted to start a website, but you couldn't work from your home on it because your home didn't have an ADA compliant restroom.

</comment><comment><USER28> Coffee shops fail because of poor management and/or poor quality. 4Barrel and Ritual succeed because they are quality focused. If you are a coffee shop- roast and brew the best coffee possible; this takes love, work, and an interest in coffee. Owners of successful coffee shops like the ones mentioned try to roast and brew the best coffee that they can. The author must not have set themselves apart from other coffee businesses in terms of quality; either that, or poor management. If you have quality and capable management it would be hard to fail. Defining coffee quality is beyond the scope of this site- methinks. ( basically, it is buying great green coffees, roasting them very well( don't burn them!), brewing them as best as you can( French Press or something without paper( and often (every 30-45 minutes))), having staff that care about keeping the quality standards ( good luck with that one!!), and thinking: about how to have better quality and be more efficient). Actually, it is fairly easy.

</comment><comment><USER29> The author notes that he did not do this out of wanting to own a business. While I believe that, I also believe that many folks who start businesses do so out of the romantic idea of owning your own business. They may not love the business but they love the idea of owning the business. I think this generally happens with people who are nearing retirement and are looking for something to do when they are done with their 9-5.

It's almost ALWAYS a bad idea. One of the common reasons for their efforts is that they want to leave something behind...either in their name or a business that can be passed on to their children. Why burden YOURSELF with the hassles of a business in your retirement years let alone make your children feel like they have to take over when you can no longer work?

If there's one thing I'd like my parents to do in their retirement, it's nothing. Enjoy life. Relax. Travel. Play golf. Show me see how enjoyable my retirement years can be.

</comment><comment><USER30> I'm glad he quotes Bourdain. _Kitchen Confidential_ is a great book and convinced me never to open a restaurant-even though cooking is my 3rd passion (behind hacking and photography)

</comment><comment><USER31> Kind of old. I enjoyed the article (and realized that coffee shop == lifestyle business) when I first read it back in 2005.

</comment><comment><USER32> First time a story is #1 on HN and reddit at the same time?

</comment><comment><USER33> "The marriage has been saved by a well-timed bankruptcy." Probably the best quote I've heard in a while.

</comment><comment><USER34> My friend and I would probably open an independent bookstore if we had no cares about making money.

</comment><comment><USER35> One thing that annoys me about coffee shops is how unfriendly people are. Mostly peering into laptops. I'd like to go to a coffee shop where people go explicitly to engage in interesting/random conversation with strangers.

<comment><USER36> Some of the best conversations I've ever had with people at coffee shops have started because of laptops.

"Whoa, is that one of those XO laptops? Do you like it? Can I try?"

</comment></comment><comment><USER37> Forget romance, go for the money.

Love what you do, but love money much more.</comment>


New language features in Java 7 - <AUTHOR> http://code.joejag.com/2009/new-language-features-in-java-7/

<comment><USER3> These changes will make a concrete improvement to my daily productivity as a Java developer. Definitely removes some of the pain points relative to other languages.

If they can also do something about closures, I'll be much happier as a Java developer when this comes out than I am today.

<comment><USER4> The Closed By mechanism seems so obvious in retrospect. What a great improvement to stability of applications overall by embedding that simple and error retardant pattern into the language.

I'm trying to understand why the collections syntax would create only immutable collections? Anyone know why so?

<comment><USER5> It theoretically permits optimizations where multiple parts of the code using the same, say, string literal can refer to the same literal. I don't believe for a moment that this is actually happening in Java, but immutable literals are not uncommon in this class of language.

</comment></comment></comment><comment><USER6> Nice to see the language maintainers finally taking the weed-whacker to the syntax.

The collection literals are nice too, but why couldn't they infer the type from the following?

      Map<String, Integer> map = {"key" : 1};

to make the syntax:

      Map<> map = {"key" : 1};

<comment><USER7> How do you know it isn't a Map<Object, Object>? ;-)

It's kind of trivial in your example, but with complex objects that implement a lot of interfaces it isn't as obvious what the programmer means.

<comment><USER8> You can always assume that it's the most restrictive type that you want. How many times did you really need Map<Object, Object>, when you initialised the map with {"abc":1, "def":2, "ghi":3} ?

Since you can always make it specific what you want, you can assume that the most common case is the "default". That's what c#'s `var` does anyways - <USER2> you have a `var a=1;`, 'a' an int, not an object. If you use `var a=new []{1,2,3};`, it's int[], not object[].

<comment><USER9> Or go one better and extend the language to do true type unification. It's not like this isn't well-travelled territory.

<comment><USER10> It's not. How many OOP languages do you know where type-inference works?

I know of none ... Ocaml uses a special syntax for reconciling the type- inference with the inclusion polymorphism that it supports ... (name : sub_type :> super_type). And IMHO it gets ugly.

I'm not really clear about what "type unification" you're referring to, but the actual types in Java aren't known until runtime (you usually only know a parent). To change this behavior an overhaul of the entire architecture is needed.

<comment><USER11> _How many OOP languages do you know where type-inference works_

C#

Not "type-inference" in the very general sense, just "type-inference" in the "when you see 'var someVar = 3;' you can infer that someVar is of integer type" sense. Which is what java is doing again. Playing catch-up to c#.

<comment><USER10> Java is not adding local type inference as in C#. It only adds the diamond construct for inferring the generic types from the variable's type being assigned ...

Map<String, Integer> m = new HashMap<>();

Which is ugly, but many Java developers are taking "programming to an interface" rule quite literally.

</comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> I'm beginning to wonder more and more whether Duby might be a bright future for writing code for the JVM.

<http://kenai.com/projects/duby>

It uses Java types, doesn't need a runtime, and most interestingly, has a pluggable compiler. The Ruby-like syntax may not be to everyone's taste, but it's nicely compact.

<comment><USER12> I found that site hard to navigate. Here's some sample code: <http://kenai.com/projects/duby/pages/Examples>

(note to self for own project: make samples very accessible)

</comment></comment><comment><USER13> Looks like Java 7 Path class will finally let you link files (yea, made it up to mid nineties Posix level). Java was always very inconsistent about what was not in the language "because some platforms may not have it (ME)" and "well we put a method there and we will throw if we don't wan't to do it (Iterator.remove())".

<comment><USER14> I hate Java with passion, but symlinks (and hardlinks) are really atrocious hacks that should never have happened, and for good reasons were deprecated more than twenty years ago by the folks that created Unix in the first place.

<comment><USER15> You can't just say something like that unqualified. My life is made better _daily_ by the presence of symlinks.

<comment><USER16> My life under Windows is made worse daily by its lack of, among other niceties of civilization, symlinks.

Hard-links would also be a nice addition. I am sure NTFS supports them deep inside it.

<comment><USER17> NTFS does indeed support both symbolic links and hard links in recent versions of Windows, and they can be created with the "mklink" command-line utility. (see: <http://en.wikipedia.org/wiki/NTFS_symbolic_link>)

<comment><USER18> NTFS _always_ supported links, but there was no interface to actually using them from the Win32 subsystem. However the POSIX subsystem could use them since NT 3.5 at least.

<comment><USER19> is this support used by cygwin?

<comment><USER20> From memory, yes. Also, GNUS uses hardlinks, and it worked for me under Windows XP.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Nice features, shame they didn't do them 10 years ago.

</comment><comment><USER22> When he says the new collections syntax creates immutable collections, does that mean modifying them creates a copy, or that objects in the collection can't be added/changed at all?

<comment><USER23> I think he meant adding a new item would create a new list. Which makes working with operation expensive but a bit safer.

<comment><USER24> You can't add items to immutable collections - if you call add() etc you'll get an UnsupportedOperationException. If you want a mutable version then you need to create a new collection, and can use the immutable collection to provide the starting values, like this:

      Set<String> mutable = new HashSet<String>(immutable)

<comment><USER25> Which is madness that completely misses the point of proper immutable collections (Clojure style) - that you _can_ "modify" them, by creating a new copy with the thing added, and it shares storage with the original and the copying isn't as slow as a copy-by-clone.

The first thing people are going to do with these half assed immutable collections is pour the contents out into a mutable container. Which completely obviates all the thread safety and whatnot.

I slap my forehead. Do these people have _no_ sense?

</comment></comment></comment></comment><comment><USER26> I'm pleasantly surprised by this. Now if we can only get properties...

</comment><comment><USER27> _Underscores in numeric literals_

This proposal was just rejected in Go, alas.

What a readability difference it makes in Ruby, Eiffel and (originally) Ada.

<comment><USER28> Heh. I was going to post that I thought this was a fairly useless feature, certainly not on par with the impact of the other new stuff. But, I can't really say that it is a bad thing... I guess.

</comment></comment><comment><USER29> nice new features. the diamond operator looks good. closures will be fun, too! starts to feel like C# (automatic resource management (C#'s IDisposable), language support for collections, strings in switch).

</comment><comment><USER30> Nice features... Code will now look a lot cleaner and concise.</comment>