New Haxe website - <AUTHOR> http://haxe.org <comment><USER2> I have a few bugs I've encountered over the weekend:

1\. The Linux binaries on the new site are a tar.gz.gz, making `tar xf filename` fail, and besides that inconvenience, is probably a packaging error. You might want to fix that.

2\. The OpenFL provided Haxe installer is broken, because it tried to download [http://haxe.org/file/haxe-3.1.3-linux64.tar.gz](http://haxe.org/file/haxe-3.1.3-linux64.tar.gz), which is gone. Please either fix the OpenFL installer or make sure download links are backwards compatible by adding a redirect. (I'm assuming both projects are run by the same community)

I worked around problem #2 by modifying the installer script to use old.haxe.org, since the binaries on the new site are harder to use because of problem #1. But this could definitely dissuade newcomers to Haxe, despite all of its qualities (which, in my opinion, are many!)

<comment><USER3> Thanks, I'll look into it.

I had a redirect for any 404s that existed on the old wiki to go to "old.haxe.org/$1", but it looks like it didn't work for the "/file/*" downloads. I'll look into it.

I'll submit a bug report re the packaging also.

</comment></comment><comment><USER3> One of the developers of the new site here. Simon Krajewski did an amazing job writing the manual - it's a great resource and has all the gory technical detail - I'd encourage you to take a look. A number of other people have contributed to content and design (though we'd still like to give the design some more love).

The website itself is developed in Haxe, and all of the content is hosted on Github so we can encourage contribution but still keep an eye on the quality, unlike the wiki we had previously. There's a "Contribute" link at the bottom of each page that links you to the relevant file on Github.

If you have any questions let me know, I'm happy to answer. I hope you find it a valuable resource.

<comment><USER4> Could you describe your web stack / how you used Haxe to develop the website, in a nutshell?

(heads up, these are returning 404s: [http://haxe.org/support.html](http://haxe.org/support.html) [http://haxe.org/donate.html](http://haxe.org/donate.html))

<comment><USER3> I don't seem to have the ability to edit, and I forgot to reply to the first part of your comment.

I use Apache/mod_neko on the server, though after the high traffic last night we might switch to nginx/mod_tora. Either way, these basically server ".n" Neko Bytecode files, and provide caching between requests [1].

I stayed away from using a database / ORM for this website, instead using Github for all the content. When we update we pull a repo and it references flat files. The site then transforms the HTML or Markdown, pops it in a template, and serves it up.

I used a library called ufront for the MVC environment on the server. You can have a look at what a controller looks like here [2]. I'm hoping to do a tutorial, ufront was written by Franco Ponitcelli and Andreas Sudderland a few years back, but I've done a lot with it in the last year and hope to release / document soon. I did do a talk at last year's conference if you're interested [3].

1: [http://jasono.co/2013/09/11/neko-web- cachemodule/](http://jasono.co/2013/09/11/neko-web-cachemodule/) 2: [https://github.com/HaxeFoundation/haxe.org/blob/master/src/a...](https://github.com/HaxeFoundation/haxe.org/blob/master/src/app/controller/DownloadController.hx) 3: [http://www.youtube.com/watch?v=c6EwJ7iU- qo](http://www.youtube.com/watch?v=c6EwJ7iU-qo)

</comment></comment></comment><comment><USER5> Interesting, never heard of it before. How can they possibly support so many targets? [1]

[1] [http://haxe.org/documentation/introduction/compiler- targets....](http://haxe.org/documentation/introduction/compiler-targets.html)

<comment><USER2> Haxe is really an under appreciated language, and I'm happy to see it gain more widespread attention. Though it doesn't bring any fancy new paradigm or language feature, it cherry picked a lot of useful and convenient parts of other languages, and combined it into a familiar, C-syntax statically typed, type-inferred language.

You can literally pick it up without reading any documentation if you're familiar with C/C++, C# or Java, and the cross platform support is really good. They mostly use source-to-source compilation, but their implementations are really robust.

To top that off, they have an excellent cross platform library in OpenFL (previously NME) that is equally easy to pick up.

</comment></comment><comment><USER6> Has anyone used Haxe in a production project? What were your experiences?

I like the end goal, but am confused why I haven't heard of it until today.

<comment><USER3> Plenty of game developers are using Haxe in production [1]. Tivo [2] and Massive Interactive [3] are doing some large scale UI work for embedded systems.

Personally I have built a student management system for 4 schools as a web app in Haxe, using it both on the server and on the client (JS). I have loved the language, but it has been a mixed affair. On the one hand some features (macros, remoting, code sharing between client & server) have sped up development hugely. On the other hand, sometimes libraries or tutorials just don't exist and you end up reinventing tools that would exist in other languages already.

The community is tiny, but really really helpful, friendly and intelligent. I recommend having a look. There is some hype and ridicule over the "run everywhere" claim but the underlying technology is a delight to work with. I hope it gets more popular support and more tutorials / libraries.

1: [http://haxe.org/foundation/who-uses- haxe.html](http://haxe.org/foundation/who-uses-haxe.html) 2: [https://github.com/tivo](https://github.com/tivo) 3: [http://massiveinteractive.com/](http://massiveinteractive.com/)

</comment></comment><comment><USER7> I think I was under the impression that Haxe was just an alternative Flash/AS3 runtime, but it appears that it is actually far more than that? Either than, or the association with Flash is obviously less important these days?

EDIT: I think that impression came from reading this [1] article, possibly found here... or possibly some other article... anyway it talked extensively about AS3 and made comparisons against Haxe.

1 - [http://www.grantmathews.com/43](http://www.grantmathews.com/43)

<comment><USER3> There is a history article [1], but essentially, the founding developer made the MTASC AS2 compiler back in the day before making Haxe, and the SWF target (AVM bytecode) was the first target Haxe supported. To this day it remains popular with the 2D games market (ex-flash). The OpenFL [2] framework promises (with mild success) to give you the Flash API with the Haxe language on native targets. So flash still is part of the Haxe community, though less and less it involves the actual Flash Player runtime.

Personally I do web development in Haxe, using Neko or NodeJS on the server, and JS on the client. I've toyed with the Java and C++ targets, but so far haven't had a single project which compiled to Flash. I find the language on it's own has a lot of features that are appealing outside of the flash environment.

1: [http://haxe.org/manual/introduction-haxe- history.html](http://haxe.org/manual/introduction-haxe-history.html) 2: [http://www.openfl.org/](http://www.openfl.org/)

<comment><USER8> Is the original developer still involved? I remember him being very hard to work with and I wonder if he's grown up a bit.

<comment><USER3> Yes, Nicolas Cannasse is still involved. He helped keep the server alive last night ;)

These days he is no longer the #1 contributor [1], but he maintains the "benevolent dictator for life" role and certainly still commits plenty of great code.

1: [https://github.com/HaxeFoundation/haxe/graphs/contributors?f...](https://github.com/HaxeFoundation/haxe/graphs/contributors?from=2012-05-27&to=2014-05-27&type=c)

</comment></comment></comment></comment><comment><USER9> I hope Haxe succeeds even more than it already has. Congrats guys.

What's a good and up-to-date Haxe tutorial for making mobile apps, targeted at Mac developers?

</comment><comment><USER10> Fantastic idea. Shame the language had to take so many cues from JavaScript!

<comment><USER3> If the curly brackets and semicolons (and lack of short lambdas, which I am still grumpy about) are always going to turn you off, then Haxe might not be promising for you.

But in particular macros [1], abstract types [2], algebraic data types [3] and static extension [4] are enough to keep me happy exploring new programming concepts etc...

1: [http://haxe.org/manual/macro.html](http://haxe.org/manual/macro.html) 2: [http://haxe.org/manual/types-abstract.html](http://haxe.org/manual/types- abstract.html) 3: [http://haxe.org/manual/types-enum- instance.html](http://haxe.org/manual/types-enum-instance.html) 4: [http://haxe.org/manual/lf-static-extension.html](http://haxe.org/manual/lf- static-extension.html)

<comment><USER10> Thanks for the links, really interesting reads and some great programming concepts.

Although I'm not a fan of curly brackets and semicolons, it's the `var` keyword which annoys me the most!

</comment></comment></comment><comment><USER11> The conference was great as well. It was amazing to hear how fast Tivo was able to port their 1M+ loc library over to Haxe, and how they're able to compile the client to new platforms now.

</comment><comment><USER12> I'm confused, what's the purpose of targeting language ([http://haxe.org/documentation/introduction/compiler- targets....](http://haxe.org/documentation/introduction/compiler- targets.html))?

I can understand e.g. people use CoffeeScript because JavaScript is more verbose. But why target Python from Haxe? Shouldn't it be the other way around?

<comment><USER13> The idea is to be able to write code in one language and use this code in many different languages.

<comment><USER14> Does it mean that it supports only basic common denominator features of every language? I am a fan of attributes in C# - are Haxe annotations as powerful?

<comment><USER3> Out of the box Haxe's metadata[1] to me doesn't appear as powerful as C#'s attributes. The big difference is that they are not type safe and are not type-checked by the compiler.

You can however use any expression you want in them, and have macros read them and confirm they are correct, and do whatever you want with them. For example I do some validation on my models:

        @:validate( _.length>0 && _.indexOf(' ')==-1 )
        public var username:String;

As for the bigger question - they are limited in what they can add, but they have many features not in other languages, they just implement them in a syntax-heavy way on the languages that lack such features. Pattern matching is a good example [2].

See [http://haxe.org/documentation/introduction/language- features...](http://haxe.org/documentation/introduction/language- features.html)

[1]: [http://haxe.org/manual/lf-metadata.html](http://haxe.org/manual/lf- metadata.html) [2]: [http://haxe.org/manual/lf-pattern- matching.html](http://haxe.org/manual/lf-pattern-matching.html)

</comment></comment></comment></comment><comment><USER15> Why does every website use broken unicode box character font import style now?

<comment><USER16> Do you use Firefox?

<comment><USER16> I ask this because Firefox can have problems loading custom fonts, especially cross domain.

</comment></comment></comment><comment><USER17> Finding some 404s about the place.

<comment><USER18> It'd probably help the developers if you linked to them.

</comment></comment><comment><USER19> Good job gyz

<comment><USER20> Atrocious spelling all around.

Please up your game a bit. I realize it's cool for the under-12 set.

<comment><USER21> Come on now, this is a thread about "Haxe"...</comment></comment></comment>


Still in love with Rust - <AUTHOR> https://dpc.pw/still-in-love-with-rust <comment><USER2> > Rust will force you to be a good programmer,

> [if] you like it or not.

This is probably the best in-a-nutshell statement that describes what a good programming language is for me.

I had similar moments in the past. Before Python I cared about indention to some degree. But once I got used to the way Python forces you to indent your code, I came to the realization that this is pretty much the way I should format my code anyway and it influenced my coding style in all other block- based languages for the better.

Clojure was another language that showed me how functional programming should be done. My code in all languages changed and I used a lot less variables and a lot more constants and parameters. My code and the systems I created became a lot simpler and much more robust as a consequence. I had used Haskell before but it never really transformed my mind the way Clojure did. I also got a really good grasp on destructuring and list comprehension.

Rust offered me several relevations. I finally understood test-driven- development because the language has excellent support for it. I also understood RAII more deeply. Traits became clear to me (Clojure protocols and Haskell type classes felt strange to me). I finally understood why the Maybe monad in Haskell/ML is one of the simplest and yet bests ideas in programming.

And there is the borrow checker. I already had a functional programming mindset when I picked up Rust. But having a clear owner of data takes the mindset of functional programming even further[1], even when mutability is involved. It is a lot easier to reason about your code when you know exactly which operations can (and should) change a variable.

An aspect that the Python, Clojure and Rust communities have in common is that they emphasize idiomatic code a lot. Therefore it is much easier for newcomers to find examples of professional-level code and learn things the right way. And it is much easier to dive into a new codebase. Clojure is actually a very extreme case of this, because Clojure code tends to use a lot of 1-letter parameter names. In most programming languages you are allowed to have the variable "i" for looping over numbers. But not much more. In contrast, Clojure has a list of well-established 1-letter variables that are recognized by everyone in the community.

[1] This does not adhere to the classical definition of functional programming but I feel that it is a natural extension to it.

<comment><USER3> Only as good as Rust allows you to be, which is fine for some until they stagnate or grow out of it; but far from the final answer to anything.

I don't get at all how being forced to do anything could ever be a good thing. Smells like cognitive dissonance from here. I'm all for powerful tools that enables me to write better code faster; but being forced, really? That's the best thing about Rust? Ew.

<comment><USER4> > I don't get at all how being forced to do anything could ever be a good > thing

If you don't prefer tools that can automatically check if you were a good developer or not, it not only does not scale (to trust the software you build), it's that I wouldn't want to work with you as a teammate.

<comment><USER5> > If you don't prefer tools that can automatically check if you were a good > developer or not

You are pretending there are no trade offs.

> it not only does not scale (to trust the software you build)

I think we should all be able to agree that empirically that is nonsense.

<comment><USER6> I have empirically witnessed that the larger a project gets, the harder it is to trust that the code does the thing you want it to do. It's far from nonsense.

<comment><USER3> True, regardless of language.

<comment><USER7> Indeed, yet different languages seem to have different slopes.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Rust is a wonderful language, but I still have the impression that it is not stable as of 2018. All the toys I've made to play with it during the last years went deprecated quickly, especially if you rely on the ecosystem of packages (web server, database, ...).

In addition, there was this thread: [https://internals.rust- lang.org/t/concerned-about-rust-2018-...](https://internals.rust- lang.org/t/concerned-about-rust-2018-stability/7932)

All in all, Rust _will_ be great when stable (including the ecosystem).

<comment><USER9> What do you mean by deprecated? Unsupported dependencies? All the code I've written post-1.0 still compiles correctly (although a lot of it could use an update to use new language capabilities).

I even have a bit of Rust in production at work and I haven't encountered any maintenance issue so far.

Now the ecosystem itself can move pretty fast depending on the dependencies you use, that's true, but that's a different issue. You're never forced to update if you don't want to, you code keeps compiling with newer Rust releases. Compared to most languages I've experienced with, Rust has been _very_ stable post-1.0. And they seem to take that issue very seriously.

The thread you linked might have some truth in it but it seems like the main point is "look, you've had a .2 patch release!" That's not a good thing of course but unless you happened to jump on that new functionality as soon as it got released the impact is rather minor and bugs happen.

<comment><USER5> > Now the ecosystem itself can move pretty fast depending on the dependencies > you use, that's true, but that's a different issue.

Is it? I'm used to languages which bundle a huge set of standard libraries as part of the language.

</comment></comment></comment><comment><USER10> "No race conditions, leaking resources, dangling pointers, unhandled exceptions, ..., the list goes on."

Except of dangling pointers, Rust has everything else from this list.

About compilation time issue: it doesn't exist anymore. Current versions do "cargo check" in a few seconds even for big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it because of incremental compilation. For libraries it takes seconds to compile and 1-2 seconds to run "cargo check" (or clippy).

<comment><USER11> It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.

<comment><USER10> Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations).

About race conditions: [https://doc.rust- lang.org/nomicon/races.html](https://doc.rust-lang.org/nomicon/races.html)

<comment><USER12> I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are _not_ panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result<> in rust).

<comment><USER10> I hate when people use __exceptions __for __regular __errors, it triggers me hard. Please let 's don't start this topic :)

<comment><USER13> You started it.... exceptions are mostly annoying because they are so verbose. Writing try... catch... is a whole lot longer than "if func() == null".

<comment><USER12> Exceptions are mostly annoying because they're infectious, and somewhat undocumented (they've not part of the api; if an upstream library adds a new exception, all downstream code must now handle it [or document it]), and if anyone misses the update, its a runtime error waiting to happen. But notably, your compiler won't say a word about it (unless its java, in which case you'll probably get too much :-). Return codes are similar, but less cascade-y. Try- catch being verbose and fucking up control flow is just an added bonus.

<comment><USER13> Which is easier:

try: module.find_element() except: # handle not found else: # handle found

Or this:

if module.find_element(): # handle found else: # handle not found

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> "Bad programmers worry about the code. Good programmers worry about data structures and their relationships."

I think this hits the nail on the head for me: abstract structure first, the choice of language C/C++/Rust/... is then a secondary consideration.

<comment><USER15> Which brings up the question when/why to pick Rust? There are a plethora of languages which from my layman perspective seem more interesting. OTOH there are a plethora of languages with rich ecosystems, proven pedigree and with a high demand for such developers.

<comment><USER16> I am working on medical devices, where a bug can have catastrophic consequences.

Essentially the ecosystem today is C and C++ for embedded FW and middleware. Even if we are careful, we rely on static analysis tools to avoid some categories of bug. (Plus a humongous amount of tests). Typically bugs that would be caught (mostly) by the Rust compiler at compile time. I think it is a great idea to have some safety guarantee at compile time.

Would Rust fixes every problem ? Absolutely not, you'll always get logical bug or implementation not conform to the requirements but I think it is a move in the right direction, and I hope that slowly in next 10 years Rust will grow in the embedded space.

And overall cargo is nice, C/C++ don't have standard package manager. The test infrastructure is there by default, this is a breeze to add them in your code, rather than relying on an external framework, so this is also good.

I don't really see an alternative today for small footprint SW where C and C++ is king, and I hope that embedded toolchain vendors are taking notes.

If today you mostly code in javascript or python, unless you need bare metal like performance or to have stronger safety guarantee, maybe it does not make sense to move to Rust.

</comment></comment></comment><comment><USER17> I'd still love to see a good tutorial on setting up Vim to work well with rls and all the other plugins. I only really keep VSCode around since it works with rls and sometimes I want to use the autocomplete for codebases that are large enough to really need good autocomplete, but not so large that rls gets bogged down and doesn't work at all anymore.

<comment><USER18> For language server autocompletion, install coc.nvim - [https://github.com/neoclide/coc.nvim](https://github.com/neoclide/coc.nvim)

Then

      :CocInstall coc-rls

and should work out of the box.

I also use [https://github.com/w0rp/ale](https://github.com/w0rp/ale) to provide linting. Also works out of the box.

You can get these things running on vim8, but honestly it's easier to just use neovim.

If it's of any use, you can check out my full config at [https://github.com/tom-james-watson/dotfiles](https://github.com/tom-james- watson/dotfiles).

</comment></comment><comment><USER19> The comment about "no race conditions" is not accurate. Rust guarantees an absence of data races which are not the same as race conditions.

[https://doc.rust-lang.org/nomicon/races.html](https://doc.rust- lang.org/nomicon/races.html)

</comment><comment><USER20> > Barriers to entry

So far I had two faltering attempts to learn Rust but somehow I didn't find good enough material to get me hooked.

I am looking for something similar to the Tour of Go[1], where you can interactively try the language by solving minimal tasks. Does someone know of such material?

[1]: [https://tour.golang.org](https://tour.golang.org)

<comment><USER21> [https://doc.rust-lang.org/rust-by-example/](https://doc.rust-lang.org/rust- by-example/)

<comment><USER20> That looks pretty good. Thanks :-)

</comment></comment></comment><comment><USER22> > Let's face it – typically developers are familiar with OOP, garbage > collected, dynamic programming languages.

I think most of these programmers, and their project are not the target of Rust? If you're writing Java/C# or higher level languages, you already made the choice to sacrifice some computing efficiency for programming efficiency.

I always thought Rust was more destined to convert C and C++ (and D/Swift/Go ?) programmers, that need the raw power and control.

<comment><USER21> We have three major audiences:

* "systems programmers", aka the C and C++ folk

* "functional programmers", largely Haskell folk

* "scripting programmers", mostly Ruby/Python/JavaScript folk

Each has gotten something out of Rust, and also brought some things to Rust.

<comment><USER23> You're missing the group which Java, C#, Swift, D and Go co-inhabit. Somewhere between "systems" and "scripting".

<comment><USER21> I did say "major" for a reason :)

I don't personally hear from many self-identified Java/C# people who are coming to Rust. Maybe they exist and I don't hear from them, or they don't describe themselves as such.

There are _some_ Go developers, but it seems the languages attract very different types of people, so there aren't many. There are some people who do love both.

There are only a few people from D (of which technically if you squint I'm sort of one, incidentally.)

</comment></comment></comment></comment><comment><USER24> Thank you for this piece. I am working on a game, that I am prototyping in Go. In my prototype, I have just entered the realm of multiple threads, and for this project to work out, it needs to handle quite a lot of threads working on the same resources.

While I have not personally dappled this far into concurrency in Go myself, I have read plenty of articles where developers recommend using the mutex package rather than the goroutines themselves.

But I've also read about Rust's thread and resource handling -- and I'll admit, I've been looking for an excuse to write some Rust again -- and so inspired by this entry, I've decided to finish the prototype in Go, and build the real version in Rust.

<comment><USER25> There was a great talk recently about how to properly build an entity component framework in Rust if you haven't seen it yet.

[https://youtu.be/aKLntZcp27M](https://youtu.be/aKLntZcp27M)

<comment><USER24> Thank you for that link. Very useful. It already highlighted a solution in Rust for a problem that I've run into with my Go prototype. And I appreciate there also was a blog post to read.[0] I personally prefer articles over videos.

[0] [https://kyren.github.io/2018/09/14/rustconf- talk.html](https://kyren.github.io/2018/09/14/rustconf-talk.html)

</comment></comment></comment><comment><USER26> Can someone familiar with both Rust and F# (or OCaml) type systems write few words about the expressiveness aspect of the language?

What would I miss in Rust if coming from the F# background?

<comment><USER21> Fun fact: Rust was originally implemented in OCaml, and takes a lot of inspiration from it. Rust was originally described to me by someone as "C meets OCaml."

The biggest thing missing in Rust that are in both are higher kinded types. The biggest thing missing from OCaml is parameterized modules.

<comment><USER26> F# doesn't actually have HKTs either, unfortunately.

<comment><USER21> I thought it did, my mistake!

</comment></comment></comment></comment><comment><USER27> Native async/await support is really great. I haven't gotten very far with Rust but it already made me rethink many things that I thought I had understood.

</comment><comment><USER28> I tried Rust a few weeks ago. Is my understanding correct that Rust doesn't have the equivalents to the following C++ features yet?

\- non-type and template template parameters

\- constexpr functions

I understand that Rust macros can replace them some of the time, and they are much better then the C preprocessor, but that's quite a low bar to meet. Last time I checked non-type template parameters (called "const generics" in Rust) is on the roadmap, so it is promising.

<comment><USER21> The equivalent of "constexpr functions" has a design, and is usable in nightly.

The equivalent of "non-type template parameters" has a design, but is not yet implemented. It's being worked on.

There's no direct design for the equivalent of "template template parameters", but a similar feature has a design, but is not yet implemented. It's being worked on.

</comment></comment><comment><USER29> Another point against Rust is binary size.

If you write the Fibonacci generator in one of the first chapters of the Rust book it will create a 4MB binary. Even stripped it's over 400KB.

If you write the same code in Nim it compiles down to 112KB with debug symbols, unstripped. Statically linked against libc (still with debug symbols) it's only 850KB.

850KB statically linked versus ~450KB dynamically linked _and_ stripped.

For code that is virtually identical.

<comment><USER30> Rust binaries include jemalloc. However, jemalloc is removed in nightly and by default Rust will use the system allocator:

[https://internals.rust-lang.org/t/jemalloc-was-just- removed-...](https://internals.rust-lang.org/t/jemalloc-was-just-removed-from- the-standard-library/8759)

This should reduce binary sizes quite a bit.

<comment><USER31> And some rough numbers, rustc-1.30.1 vs rustc-1.32.0-2018-11-21, building a hello world with --release...

Mac OS:

\- 1.30.1 before strip: 573K, after strip: 380K

\- 1.32.0 before strip: 267K, after strip: 178K

Ubuntu 18.04 LTS:

\- 1.30.1 before strip: 3.9M, after strip: 407K

\- 1.32.0 before strip: 2.3M, after strip: 191K

<comment><USER29> I'm on Void Linux right now running Nim 0.19 compiling the following code:

        when isMainModule:
          echo "Hello World"

_nim c hello.nim_ :

Before strip: 113k

After strip: 92k

 _nim c -d:release hello.nim_ :

Before strip: 79k

After strip: 63k

 _nim c -d:release --opt:size hello.nim_ :

Before strip: 46k

After strip: 30k

Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbols is still 78k smaller than the stripped, release version of the Rust equivalent. But it's great that they're trying to work on this problem.

<comment><USER31> >But it's great that they're trying to work on this problem.

I don't know how the Rust team thinks, but I believe that minimizing binary sizes is not a very big priority for them. The cost of a gigabyte these days is, ~0.01$ (or less) for local hard drives, $0.4 for NVME and about $0.1 for AWS EBS...

Technically of course it's cool how small Nim binaries are, and it does make certain things feasible which with larger binary sizes might be difficult.

<comment><USER21> We think it's important to be able to control it if you need to, and have done work to make that possible. But we don't worry about the default _too_ much, as you say, we've got a lot of things to worry about, and it's not near the top of the list.

That said, the smallest executable produced is 145 bytes: [https://github.com/tormol/tiny-rust- executable](https://github.com/tormol/tiny-rust-executable)

</comment></comment></comment></comment></comment></comment><comment><USER32> The moment a programmer conflates OOP with 'complicated graphs with lots of interdependencies between nodes', it's the moment I stop reading their writings.

OOP does not force one write complicated graphs of objects. OOP has its applicability, FP has its applicability and well-written code in conventional languages is a mixture of those two.

</comment><comment><USER33> > Now I see how before Rust I was often writing my code in a typical OOP-way: > forming complicated graphs, with many objects referencing each other, with > unclear relationships. The class APIs, inheritance hierarchies, were there, > but they were just obstructing the core problem: structuring and > manipulating data... Rust will force you to be a good programmer, you like > it or not.

Rust today demands static knowledge of all relationships. But class APIs, inheritance hierarchies, and the like are powerful tools for dealing with _dynamic_ relationships: code that runs together yet evolves separately, where Rust is feeble. Good programmers recognize that different problems require different solutions!

<comment><USER34> Rust is feeble at patterns it wasn't made for (OOP), absolutely. :). Composition over inheritance.

</comment></comment><comment><USER34> Rust core development is working on many important features in parallel. The feature I have been most excited about, and wish was here already, is async/await. I wrote quite a bit of asyncio using futures and it was a bloody, exhausting experience. Lack of documentation or examples made the experience even more challenging. Much of what I wrote _could_ be trivially refactored to async/await syntax, but I may keep some around to honor hard-earned gains. It's not clear to me yet whether the first stable release in Q1 2019 will allow me to port everything but I look forward to finding out.

</comment><comment><USER34> dpc, the author, is such a helpful, positive force at the #rust-beginners IRC channel

</comment><comment><USER35> Rust still lacks an effect system, though. Any plans?

<comment><USER21> No current plans.

</comment></comment><comment><USER36> _Bad programmers worry about the code. Good programmers worry about data structures and their relationships._

Mildly horse shit. It takes both on a team.

</comment><comment><USER37> How does data-centric work? How is it different from OOP? Can someone elaborate for a person using python?

Also, what opinion rust devs have over golang?

<comment><USER21> > How does data-centric work? How is it different from OOP?

Rust doens't have objects. You have structs, which are purely data, and functions, which are purely behavior. OOP puts the two together. So in Rust, you don't _tend_ to design things by saying "what are the objects I need?" but rather "what is the data I am manipulating and how do I manipulate it?"

> Also, what opinion rust devs have over golang?

I am not 100% sure what you're asking here, could you maybe re-phrase? Are you asking why Rust is better than Go?

<comment><USER37> Oh nice, good to know.

> Are you asking why Rust is better than Go?

No, just the opinion in general, why rust over go? I know go is more oriented to distributed systems, but it seems like rust eventually will be used for that as well. And I also see golang being used to build just anything, like gopass for example.

<comment><USER21> Ah. That's a more interesting question, for sure. :)

I got involved with Rust over Go because if I'm going to use a statically typed language, I need generics. That was the initial thing, but other things ended up going similar ways (I think package management is extremely important, for example.)

I think Go has made great choices to accomplish its goals, but I'm personally more interested in a different set of tradeoffs.

</comment></comment></comment></comment><comment><USER38> Rust sounds like the dream. I gotta check it out sometime

</comment><comment><USER39> I was going to try out Rust, then I saw this on the download page

      curl https://sh.rustup.rs -sSf | sh

Really?

<comment><USER21> Yes.

The script is less than 400 lines, and is pretty easy to audit. We wrote it in such a way to prevent some issues like "if the download gets cut off only part of the script gets run." It's served over HTTPS.

You can also probably get an install from whatever package manager you use, if you prefer that.

<comment><USER40> You can detect whether the script is being piped into sh, so downloading the script via for example FF might produce different results than piping it to shell, making audits useless.

<comment><USER21> Sure. If you're worried about that, it's easy enough to download it first, and then run it, without the pipe.

If you're auditing it, you've already downloaded it, so it's unclear to me why you'd re-download and pipe rather than just running it.

<comment><USER41> You still have zero guarantee that other people are getting the same code.

Encouraging people to run code from some random URL on the Internet is always bad.

</comment></comment></comment></comment></comment><comment><USER42> Can't have a Rust post without a mention of D.

</comment><comment><USER43> Am I the only one who really can't stand rust?

I was and still am very much in favor of the ideas and concepts, but when I actually tried to use it my opinion on it turned by 180°:

\- The syntax is awful \- No dynamic libraries \- Slow compile times \- Many checks are too stupid to figure out some valid cases (maybe that improved meanwhile)

<comment><USER21> You are not.

\- No dynamic libraries

This is _technically_ incorrect, but practically correct, by the way.

> (maybe that improved meanwhile)

The next version, released on December 6th, ships "non-lexical lifetimes", which does make the borrow checker smarter.</comment></comment>


Dutch Startup Converts Heat into Cold via a Stirling Engine - <AUTHOR> https://www.forbes.com/sites/johnkoetsier/2019/01/18/this-dutch-startup-converts-heat-into-cold-via-a-stirling-engine-and-could-just-save-the-planet/#433e23566744 <comment><USER2> "If you don't understand how that works, you're not alone. I don't either." I often ask myself do we need this type of journalism at all?

<comment><USER3> I like to know how things work, so I spent some time reading up on Stirling engines and then returned to the article. But it's not hard for me to imagine someone wanting to read about what the article covered: the invention of the unit, it's implications, etc without having to dig into the technical depths of its implementation.

</comment></comment><comment><USER4> I'm getting really tired of startups getting a pass on basic physics. Presumably because people are hungry for magic technological changes even though they aren't going to happen.

Self filling water bottles, solar roadways, hyperloop, Mars colonization; it's just infuriatingly easy to capture the imagination, and dollars, of hopelessly hopeful "futurists".

No it's not possible that you can convert heat into cold without creating more heat than you started with. This is obvious. Hypothetically, a value add could be less accidentally-created heat, but if that's the value proposition, I wish they would talk about that in sufficient detail to be convincing instead of impossible marketing twists.

I mean, if the Stirling engine based tech was that much better and is that old, why do we have compressor-based AC at all?

It's the same thing with the hyperloop. The damn idea is 100 years old. In a world of shinkansen, you'd think if hyperloop was feasible, it would already exist.

<comment><USER5> Whenever you read a Forbes article, check if it's by a "contributor" if it is, that means they payed Forbes to publish the article. Generally anytime I see a contributor article I get ready for a good laugh

</comment></comment><comment><USER6> www.soundenergy.nl/theac-25

They should have thought harder on that name, it's one missing R away from the infamous Therac-25

</comment><comment><USER7> I can't wait until they invent a magic machine to turn numbers into pictures!</comment>


Y Combinator, Silicon Valley's Start-Up Machine - <AUTHOR> http://www.nytimes.com/2013/05/05/magazine/y-combinator-silicon-valleys-start-up-machine.html?partner=rss&emc=rss

<comment><USER2> This is really great. I worked along side these guys (strikingly) in the same cafe in SF, hacking away for a while before they got into YC. These guys are humble and really doing it right.

They took what others just see as a clone of weebly and have added enough USP to prove that it's all execution. They had customers even while sitting in the little Cafe in SF and have growing fast through sheer force of will !

Biggest thing, humble, not afraid to ask for help and thick as thieves.

These guys are what every entrepreneur should be trying to attain in a team !

</comment><comment><USER3> The strikingly folks have done a fabulous job in creating a niche in such a over-competed market and making Strikingly.com closer and closer to perfection. I sat in one of their founder-user connection events in Chicago a few days ago. Amazing how much they care about the users and would do anything for them even including suggesting an alternative web-building service if the users have the needs.

</comment><comment><USER4> The story is so baller and I met them and visited them while they were still cramped on futons. The dudes have stuff that legends are made of. Looking forward to more good things from you guys. Just as inspirational as mount fuji that I'm seeing through my shinkansen Window. Totally worth tapping off on the phone for this.

</comment><comment><USER5> Link to the single page version : [http://www.nytimes.com/2013/05/05/magazine/y-combinator- sili...](http://www.nytimes.com/2013/05/05/magazine/y-combinator-silicon- valleys-start-up-machine.html?partner=rss&emc=rss&pagewanted=all)

</comment><comment><USER6> David, Dafeng, and Teng - In case I didn't make it clear before: You guys are a fucking inspiration. March on strikingly.

<comment><USER7> Thanks a lot man. It means a lot to us.

</comment></comment><comment><USER8> Very good read. Gives me the motivation to keep going. :)

</comment><comment><USER9> Interesting story (since nobody seems to be commenting here on _the_ story) about the author, Nathaniel Rich:

[http://gawker.com/nathaniel-rich-is-different-from-you- and-m...](http://gawker.com/nathaniel-rich-is-different-from-you-and- me-478646630)</comment>


Count on Geeks to Rescue the Earth (or why not everyone should be a social worker) - <AUTHOR> http://www.wired.com/techbiz/people/magazine/15-09/st_thompson I've gotten into more than a few arguments with people who disparage entrepreneurs (read capitalists) as greedy, and too insensitive. What do you think the world would be without some of them? Bill Gates, Warren Buffet, greedy, I think not. <comment><USER2> Malaria is an interesting case. It was our sympathies for the poor little birdies dying of DDT that doomed millions of people to death. Next time you hear about the wicked conservatives, just remember that most of the mass murders of the world have come from the left...with moral righteousness and absurdity combined in full force.

Still, there's something sensible (in a primal way) about our sympathies for one suffering servant, but not a hundred. When that many people are dying it strongly suggests that the malady is an epidemic...and that our best strategy is evasion.

<comment><USER3> I don't know the story very well, just wondering: what were people doing before DDT was even invented? I am guessing that because of DDT the structure of the population changed, so that when it was taken away, millions of people were exposed to Malaria, who would not even have existed without DDT?

</comment></comment><comment><USER3> I am not entirely convinced by the arguments yet. Maybe it really makes more sense to donate to individuals? I think what we like to see is our donations have an effect. It is easier to imagine that one child could be helped, than that 8 children could be helped. Looking at a whole country full of squalor, one simply doesn't feel as if one could make a difference. I mean it is not that we feel less sorry about the mass of suffering people, only less confident in out ability to help.

OK, so that would still be a problem of perception. On the other hand, I am also not sure that I accept the other premise of the article, that throwing lots of money at a problem is going to make it go away. It is great what Bill Gates is doing, but it has not yet proven that it will work, or has it?

</comment><comment><USER4> This geek numbers theory is pretty weak. I think the main reason he'll be so effective is that he's not a stupid bureaucrat. Not only is he not a stupid bureaucrat, he's a really smart guy with tons of experience learning how to win.

Most politicians who are responsible for running government aid programs could never dream of taking over as CEO of Microsoft and being successful. That requires actual ability and intelligence, neither of which are required to be a politician.

Bill Gates is doing the same thing he did to a lot of huge companies (like IBM). He's showing them what happens when you have someone who's not a mediocre hack running things.</comment>


RMS: What is GNU? - <AUTHOR> http://www.omnisio.com/v/db0v1UTdjhG/what-is-gnu

<comment><AUTHOR> From the movie "Revolution OS": <http://video.google.com/videoplay?docid=7707585592627775409></comment>


China Loses Zen: AMD Halts Technology Transfers of x86 IP - <AUTHOR> https://www.tomshardware.com/news/amd-zen-china-x86-ip-license,39573.html <comment><USER2> So AMD handed over their most valuable IP for basically nothing. Just another example that doing business in China is a pyrrhic victory.

<comment><USER3> > So AMD handed over their most valuable IP for basically nothing.

Can you elaborate on how you get this conclusion?

From the article "agreed to license its x86 and SoC IP for chip development in a deal worth $293 million (plus royalties)", that's at least 5% of AMD's 2018 revenue (out of 6 billion).

<comment><USER4> Which is very little for everything given away</comment></comment></comment>


Is massively collaborative mathematics possible? - <AUTHOR> http://gowers.wordpress.com/2009/01/27/is-massively-collaborative-mathematics-possible/ <comment><USER2> Yes! See [http://www.nature.com/nature/journal/v461/n7266/full/461879a...](http://www.nature.com/nature/journal/v461/n7266/full/461879a.html)

</comment><comment><USER3> there seems to be an opportunity for designing a new kind of forum to facilitate this sort of collaborative work. perhaps the traditional threaded model of forums like HN, phpbb, and others isn't optimal for this sort of collaboration.

</comment><comment><USER4> Perhaps the Wave protocol could be adapted to this sort of purpose. It seems designed for it, really.

<comment><USER5> There's already a LaTeX bot called watexy.

</comment></comment><comment><USER6> This seems quite similar to the question "Is open source software viable?"

<comment><USER7> Except that in open source software there are well known ways for splitting up work. In mathematics... thats not really the case (or at least, not to the same degree).

</comment></comment><comment><USER8> Is massively collaborative pregnancy possible?</comment>


Best VPN deals for business security - <AUTHOR> https://medium.com/@jayhopej3/black-friday-2018-best-vpn-deals-for-business-security-5e4bc3c2003b <comment><AUTHOR> I've been reading more and more about business data protection, it looks like the VPN market might expand from B2C to B2B too. Hope some of you might find this helpful.</comment>


Facebook marketing: one of the better campaigns I've seen - <AUTHOR> http://ohashi.info/story/12/20/2009/nyquil-facebook-marketing I found this to be one of the most compelling marketing campaigns that I have personally witnessed through facebook.  Maybe because of my demographics I've missed some others?  Would love to see others share what they thought were good ones.  The only other one I liked more was the IKEA tag for ownership one. <comment><USER2> This seems pretty standard for relatively high-budget Facebook campaigns. Create a group, maybe an app, buy ads with a meek little social feature, and watch high traffic * low conversions turn into a meaningless number of fans.

<comment><USER3> Maybe this is standard, but I hadn't thought of it (not a marketing type) -- so it was useful for me, at least. They may have only a group of "fans", but I am not convinced that it's "meaningless". They have 30,000 people that are 1) thinking about the product and are therefore somewhat more likely to use it, and 2) social validation that it might be a good group to join.

<comment><AUTHOR> actually when I watched it grow, within a day it was around 100,000 members. it grew impressive fast.</comment></comment></comment>


AWS mistakes to avoid - <AUTHOR> https://cloudonaut.io/5-aws-mistakes-you-should-avoid/ <comment><USER3> Full disclosure: I work for Linode and I am super biased. This is my own opinion etc etc

Perhaps the first AWS mistake you might make is... using AWS? Even before I started at Linode, I thought it was terrible. It's extremely, unreasonably pricey. The UI is terrible. Their offerings are availble elsewhere. I started MediaCrush, a now-defunct media hosting website, on AWS. After a while, we switched to dedicated hosting (really sexy servers). We were looking at $250 a month and scaled up to millions of visitors per day! I ran our bandwidth and CPU usage and such numbers through the AWS price calculator a while ago - <USER2> $20,000 per month. AWS is a racket. It seems to me like the easiest way to burn through your new startup's seed money real fast.

Edit: not trying to sell you on Linode, just disclosing that I work there. There are lots of options, just do the research before you reach for AWS.

<comment><USER4> Since you're dealing in absolutes, let me return the favor; you're being a little silly.

Yes, Linode beats AWS when it comes to price. On the other hand, Linode's offer is incredibly basic and simplistic. AWS offers service after service that Linode simply doesn't and realistically cannot.

Sure, you can emulate a subset of these services (and a subset of their features) using open-source software but at what price ? That's the major flaw in your reasoning. Getting to the point where your installations are as stable and reliable as AWS', given a large stress on the system, will cost you a lot of money and time. Directly comparing the cost of hardware access is ignoring other costs and headaches that are not very easy to estimate.

There's a market for a service like Linode and there's a market for a service like AWS. You've simply never worked on a project/system that works better on AWS than on Linode. I know I couldn't run the systems that I currently operate on Linode without multiplying the workload that is needed to maintain them.

Linode and AWS are competitors but there's space in the market for both; they simply fill different niches. Establishing one as absolutely superior to the other is silly and closed-minded. A lot of people chose AWS; go and ask them why (feel free to reach out to me at nick at nasx dot io - I'll be more than happy to talk to you).

<comment><USER5> I'm really not trying to compare Linode to AWS here. I just felt that it was necessary to mention that I work for Linode because there _is_ some overlap. I'm really also not trying to sell anyone on Linode in particular. I'm pointing out that from my own personal experience, AWS is grossly overpriced and worse than the alternatives for a large number of use-cases.

<comment><USER6> AWS is insanely overpriced. It's weird to me that everyone jumping on AWS and some of their customers never come close to attracting the internet traffic required to set up CloudFormation. I think if you're starting a webapp out of your own pocket and not millions of dollars of investors, it makes sense to save where you can.

Using locust.io, I've seen that my current site on two $10/month Linodes can scale up to approximately 300k people/day and increasing that substantially just means I press a button and upgrade my app/database servers.

If it came to a point where I was growing at a pace I didn't want to manage and money was flowing in, and I was out of ideas on software optimization, only then I would consider spending tens of thousands/month on AWS.

I'm not denying the great benefits AWS gives, I honestly would love to use it now and just be done with most of my devop headaches, but the costs are prohibitive.

<comment><USER7> What are some alternatives to AWS? Are there realistic alternatives?

<comment><USER8> The "alternatives" depend on your situation.

Picture a continuum between brain-dead simple websites and business-critical complex websites:

      simple:  static website, WordPress blog
      moderate:  small business CMS, etc
      complex:  Netflix, AirBNB

If you're running a simple WordPress blog, the AWS prices are absurdly overkill. For this use-case, there are a zillion alternatives. Linode, Digital Ocean, Rackspace bare metal, etc, etc.

On the other end of the spectrum, you want to run a high-availability website with failover across multiple regions like Netflix. You need the value-added "services" of a comprehensive cloud provider (the " _I_ " and " _S_ " in " _IaaS_ " as in " _Infrastructure Services_ "). For that scenario, there are currently 4 big competitors: AWS, MS Azure, Google Compute Cloud, and IBM SoftLayer. However, many observers see that Google and IBM are not keeping pace with AWS and Azure on features so at the moment, it's more of a 2 horse race than a 4.

Keep in mind that the vast majority of cost comparisons showing AWS to be overpriced are based on comparing Amazon's EC2 vs bare metal. The EC2 component is a small part of the complete AWS portfolio.[1] If you're doing more complicated websites, you have to _include the costs_ of Linux admins + devops programmers to reinvent what AWS has out of the box. (The non-EC2 services.) Even if you use OpenStack as a baseline for a "homegrown AWS", you'll still need extensive staffing to configure and customize it for your needs. It may very well turn out that homegrown on Linode is cheaper but most articles on the web do not have quality cost analysis on the more complicated business scenarios. Anecdotes yes! But comprehensive unbiased spreadsheets with realistic cost comparisons?!? No.

[1][https://aws.amazon.com/products/](https://aws.amazon.com/products/)

<comment><USER9> Digitalocean is a great alternative for simple things.

I use it for dev / early projects and as things get complex or need more redundancy I make the production spend on AWS.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> You know what I've realized that's really important. More AWS tutorials is really needed. There's numerous of new programmers who want to learn AWS, but can't finish building anything because they get buried in documentation.

I find there are a lot of high-level abstracted tutorials, but for the new services, there aren't a lot of detailed tutorials.

For instance, an implemented cognito->gateway->lambda->dynamodb is really hard for a newbie to do.

<comment><USER11> I definitely agree that better tutorials and/or a simpler interface would makes AWS more accessible and user friendly.

A YC S15 startup, Convox ([http://convox.com/](http://convox.com/)), aims to "make AWS as easy as using Heroku." It looks really promising.

<comment><USER12> Convox member here. Thanks for the shout out.

This is definitely a goal of Convox: to remove as much AWS complexity as possible.

Our approach matches this guide to a tee. We are using CloudFormation to set up a private app cluster, as well as to create and update (deploy) apps. We are also using ASGs.

The instance utilization point is spot on too. The fist thing convox does to make this easy is a single command to resize your cluster safely (no app downtime).

Coming next is monitoring if ECS and CloudWatch and Slack notifications if we detect over or under utilization.

I strongly believe that these AWS best practices can and should be available for everyone. For anyone starting from scratch or migrating apps off a platform or EC2 Classic onto "modern" AWS.

<comment><USER13> I hadn't heard of Convox before, but it sounds interesting.

I'd like to use AWS more, but each time I tried to get into it I felt overwhelmed. I currently use PagodaBox a lot, which is great (most of the time) because it handles a lot of the complexity for me, but it can often be expensive. How does Convox compare to PagodaBox?

<comment><USER12> I've never used PagodaBox but it looks like a nice PaaS.

Convox has the same goal of a PaaS: to give you and your team an easy way to focus on your code and never worry about your infrastructure.

One big difference with Convox is that we accomplish this with single-tenant AWS things. You and your team's deployment target is an isolated VPC, ECS (EC2 container service), and ELB (load balancers).

If you're asking for a cost comparison, we're building Convox to be extremely cost competitive by unlocking AWS resource costs for everyone.

Its easiest to compare the cost of memory across platforms, though not always apples to apples...

The base Convox recommendation is 3 t2.smalls which is 6 GB of memory which costs about $100 / month. If your app can be sliced up into 512 MB processes, you can easily run 10 processes, which could be 2 to 5 medium traffic PHP apps on the cluster.

I'm finding PagodaBox pricing calculator a bit confusing but 6 512 MB processes, so 3 GB of memory, is $189.

<comment><USER11> So eventually Convox will have to make money, but I'm not sure I see the path... given that I have free access to the software and the infra is provided by AWS.

Do you plan to eventually charge a monthly fee for using the command-line tool?

<comment><USER12> Thanks for your question. A much more thorough pricing page is in the works.

The most straightforward model, and where we are already making some money, is running a Convox as a managed service.

In this setup you and your team get Convox API keys. Convox installs, runs and updates everything for you in our accounts. You get a monthly bill that's your AWS resource costs plus a percentage to Convox for management.

We will be tweaking this model to sell packages so bills are really easy to understand.

Some other experiments we're doing...

We sell support packages and professional services for app setup, migration and custom feature development.

We have a per-seat model for productivity features. Private GitHub repos and Slack integrations are $19 / user / month. There are more closed SaaS tools like this coming.

Infra is trending to commodity prices industry wide.

We'll be selling SLAs, support, productivity tools on top of that infra.

You'll get a cutting edge private platform without hiring and managing your own devops team to build and maintain it.

Open source users will help grow the user base and make the platform better without us running a freemium platform.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> _> There is no reason - beside manually managed infrastructure - to not decrease the instance size (number of machines or c3.xlarge to c3.large) if you realize that your EC2 instances are underutilized._

CPU/Memory aren't the only measures of underutilization. If you require high instantaneous bandwidth throughput, then the networking capacity available to your instance roughly increases with the size of your instance. This includes both EBS as well as other Network traffic.

Table with Low/Medium/High: [https://aws.amazon.com/ec2/instance- types/#instance-type-mat...](https://aws.amazon.com/ec2/instance- types/#instance-type-matrix)

Example benchmark with c3 instances: [http://blog.flux7.com/blogs/benchmarks/benchmarking- network-...](http://blog.flux7.com/blogs/benchmarks/benchmarking-network- performance-analysis-of-c3-instances-using-iperf-tool)

If you're more concerned with just EBS network throughput, check out the table on this page instead: [https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs- ec2-...](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs- ec2-config.html)

<comment><USER15> This is super important - I've run a number of 'oversized' instances just to get better networking. AFAIK none of the cloud providers offer a way to create a 'network' optimized instance, though containerized deployments should help with under utilizing the rest of the instance.

<comment><USER16> This was a big issue for me too. Google Compute Engine seems to have no throttling like AWS does, or at least it's a much higher cap. On an n1-standard-1 I routinely get 250+ MB/s, and near 1 GB/s for n1-standard-4 and larger. The only high bandwidth AWS instances I've found are the few expensive ones that spec 10 Gbit.

<comment><USER17> According to this page, you can get ~14Gbit networking on Google Cloud's n1-standard-8

[http://googlecloudplatform.blogspot.com/2015/11/bringing- you...](http://googlecloudplatform.blogspot.com/2015/11/bringing-you-more- flexibility-and-better-Cloud-Networking-performance-GA-of-HTTPS-Load- Balancing-and-Akamai-joins-CDN-Interconnect.html)

</comment></comment></comment></comment><comment><USER18> I'd like to add, if using Elastic Beanstalk, don't directly attach an RDS instance when creating the environment. If you do, you won't be able to destroy your environment without also deleting the RDS instance. Instead, create the RDS instance separately, and just add the proper security group for the environment to be able to access the host. Then you can easily create a new eb environment with any config changes (there are some config changes you can't make to an eb environment without creating a new one from scratch) and then connect to your existing db.

<comment><USER19> interesting. i was under the impression you could just create a snapshot (before destroying the environment) and then restore as needed. am i missing something?

Edit: [http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_R...](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RestoreFromSnapshot.html)

<comment><USER20> If you can take the database instance offline and if you do not need to access it from outside of the beanstalk app then that is fine.

</comment></comment></comment><comment><USER21> Another, somewhat obvious one:

Be extremely careful when using public customized AMIs, a lot of times ~/.ssh/authorized_hosts contains public keys and this is obviously a huge security problem

<comment><USER22> no, public keys are not a security problem.

<comment><USER23> They are if you don't know who has the corresponding private key.

<comment><USER22> oh right when using public AMIs. I thought parent meant publishing AMIs. derp.

</comment></comment></comment></comment><comment><USER24> I like CloudFormation. Unfortunately it is very unwieldy to write CloudFormation templates directly, and we're not about to start using the AWS CFN GUI editor!

It seems like the assembly of the AWS ecosystem.

Does anyone else have a favourite hammer for this particular nail? I'd love to have something better than our home-baked solution, but I'm yet to find anything which doesn't introduce other flaws, such as an incomplete implementation (missing parameters or resource types) or ultimately making a leaky abstraction on top of CloudFormation somehow.

I ended up brewing a reasonably straightforward solution using Python as a (minimal) DSL which emits JSON. Its primary purpose is to support _the whole_ of the CFN ecosystem (not just implement some small part of EC2, for instance) while also not trying to be too clever.

It has about 50-100 lines of python which implements helper functions such as ref(), join() and load_user_data(), and not many other things. There is an almost 1-to-1 correspondence between the generated CFN configuration and the python source. As a bonus it checks for a few common mistakes like broken refs or parameters which aren't used.

I have heard that similar solutions have been reinvented in a few places, including the BBC. But I'm yet to see a good public solution!

<comment><USER25> If you'd consider something other than CloudFormation, there is also Hashicorp's Terraform. It has an AWS provider ([https://terraform.io/docs/providers/aws/index.html](https://terraform.io/docs/providers/aws/index.html)) which creates resources and maintains the state in a file that you can store in version control ([https://terraform.io/docs/state/index.html](https://terraform.io/docs/state/index.html)).

<comment><USER26> Terraform, as an idea, is brilliant. Mitchell and company isolated a hugely important need and tried to fill it, and I give them all the credit in the world for that. Cross-platform cloud provisioning? Gimme. But I cannot in good conscience not relate what a disastrous experience Terraform has been for me at both jobs and clients.

Writing reusable code in Terraform is an exercise in frustration due to the extreme clumsiness of HCL (which, I understand, was used because "YAML is complicated"\--well, that's true, but YAML isn't a good solution either, you're _HashiCorp_ , you wrote _Vagrant_ , you already know how to do this!). The application architecture is reckless and full of race conditions; your state _will_ be hosed if one resource errors out at the wrong time, while other resources are being successfully updated--the resources that return successfully after the failed resource will on many occasions fail to be persisted to state. What's more, application testing seems to be at best an afterthought: there have been regressions in the providers that will break your _existing_ states.

I would under no circumstances use Terraform if I didn't have clients who had selected it before I was working with them. If in AWS, I would use CloudFormation, with a tool like Cfer[1] (which is excellent, reliable code) or SparkleFramework[2] (which is more full-featured but I hope you never need to debug it) to provision my stuff.

(Full disclosure: I'm building a much, much better provisioner for multi- provider cloud infrastructure. Neither of the projects I recommend are mine; mine's not done yet.)

[1] - [https://github.com/seanedwards/cfer](https://github.com/seanedwards/cfer)

[2] - [http://www.sparkleformation.io/](http://www.sparkleformation.io/)

<comment><USER27> If you're writing your own, you might also look to BOSH[1] for inspiration.

It's older than CloudFormation and Terraform (born 2010). It can manage anything that someone's written a driver for. So far that includes AWS, Azure, vSphere/vCloud, OpenStack, VirtualBox, Google Compute Engine, Apache CloudStack and there might be others I missed.

It stores state in a database. It is able to recover from mismatches between the state of the world and the desired state. Cloud Foundry users have been using it for years to deploy and update CF installations. Pivotal Web Services (I work for Pivotal, in a different division) has been upgrading to the most recent CF release every few weeks, live, without much fuss, for years.

For any kind of heavily stateful infrastructure, BOSH is a strong candidate.

[1] [https://bosh.io/](https://bosh.io/)

<comment><USER26> Augh, how did bosh slip my mind? I've never used it in production, but I've used it to roll out a CF environment for testing and was impressed to dig into it a little more (most of a year ago now, I think your mention of CF was actually what kicked that off). From (admittedly limited) experience I'm not crazy about its developer-facing feel, but I appreciate the significant and _responsible_ effort in it.

</comment></comment></comment></comment></comment><comment><USER28> Also, dont use Dynamo unless you have a really good reason. "It scales better than MySQL" is not a good reason.

Have fun migrating data and re-indexing constantly!

<comment><USER29> Is local secondary indices and lower operational costs than Cassandra a good reason(s)?

<comment><USER30> Operational costs are in the eye of the beholder. We evaluated DynamoDB for a new use case but we're going with Cassandra because the storage costs alone more than made up for ops overhead. At least IMO, Cassandra's support for multicolumn range queries (via clustering columns) and the cheaper storage you can use obviate local secondary indices. (Cassandra has secondary indices as well but it seems like most folks prefer further denormalization--at least, that's what we're doing.)

</comment></comment></comment><comment><USER31> My huge recommendation is to put production instances in a completely seperate region than development and staging instances. I actually just discovered that you can limit IAM API keys to a specific region, you just need to create a custom policy. The following policy is an example:

        {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "SOME-ID-HERE",
                "Effect": "Allow",
                "Action": [
                    "ec2:*"
                ],
                "Condition": {
                    "StringEquals": {
                        "ec2:Region": "us-west-2"
                    }
                },
                "Resource": [
                    "*"
                ]
            }
        ]
        }

<comment><USER26> Why would you do this instead of using multiple AWS accounts? Different regions have different feature sets (available instance types, beta eligibility, etc.). I strongly recommend instead using multiple AWS accounts instead and keeping them in the same region.

That said, since you should be using an infrastructure provisioning tool like CloudFormation, the tagging solution should not be a particularly big obstacle.

<comment><USER22> yes, use multiple accounts. you can use STS to grant permissions between the accounts if needed.

<comment><USER31> STS works, but I feel like multiple accounts linked is more of a hack than using a single AWS account. Of course, if you use a service that is not available in both regions, use STS.

<comment><USER32> How is multiple accounts a hack? It's the correct solution to isolation. Using regions is just stupid because now you've attached extra meaning to regions and can't bring up production stuff in other regions for better latency.

</comment></comment></comment></comment></comment><comment><USER33> The biggest mistake I've seen with AWS (and committed myself), is not reading the manuals for the services you're using. While some people complain about the AWS manuals not being complete, there is still a lot of good information in there that you might miss if you're just clicking through the console.

</comment><comment><USER34> I wonder if AWS is a good location to run a VoIP server. VoIP is a real time application that is very prone to jitter, latency and packet loss. I'm concerned about "noisy neighbors" and decreased network performance at AWS.

Does anybody have experience with running a VoIP (e. g. Asterisk) on AWS?

<comment><USER35> I sell an application built around VoIP. I dislike running my own servers, so just lately I moved them to AWS.

At first, I used instances that were not very performant, causing some problems. I quickly moved to more powerful instances and since then there have been no problems at all. There is a slight delay, which is normal, since the servers are not in the same country as the users anymore, but the users haven't noticed it at all.

I can't say how well it scales, though. I have a small user-base, so scaling has not been a problem yet. Network performance might become a problem if you have a huge user-base.

<comment><USER36> How can you be sure that your users haven't noticed?

</comment></comment></comment><comment><USER37> I second the recommendation to use CloudFormation + packer + ELBs + auto scaling groups for web applications whenever possible, it just makes everything so easy and automatic. Of course, there's a learning curve and you pay a premium for all that automation, but in my experience it has been usually worth it so far.

<comment><USER38> I like going one step further and making deployments and AWS resources into reusable code using Troposphere: [https://github.com/cloudtools/troposphere](https://github.com/cloudtools/troposphere)

</comment></comment><comment><USER39> I wonder when Amazon is going to invest their ungodly earnings into UX. Their UI is absolutely terrible and I shudder every time I have to log into it. Is it purposely built that way to confuse people who don't belong in there?

<comment><USER40> I've heard this a few times -- AWS is a very complex product that gives you a lot of freedom in how you build your product using it. I think the web UI works about as well as it could given that complexity.

If you want something simpler, you have Heroku and a bunch of similar things which make a bunch of decisions for you -- but you don't have the flexibility there that you do with AWS of course.

<comment><USER39> There has to be some middle ground between AWS and Heroku though.

<comment><USER40> There are some options, but the point is, what you're trading for simpler UX is a simpler overall product with less flexibility.

</comment></comment></comment></comment><comment><USER41> Use OpsWorks if possible. It's free and provides a simple interface that allows you to deploy/upgrade your apps automatically and monitors your instances automatically using CloudWatch.

<comment><USER30> +1. AWS has done an amazing job with OpsWorks. It's free Chef 12. What's not to love? (The only drawback I've noticed so far is some standard Chef stuff-- vault in particular--not working. Other than that, very pleased.)

</comment></comment><comment><USER42> Check out [http://convox.com/](http://convox.com/) (YC S15) for an alternative to avoiding manual infrastructure.

<comment><USER12> Convox co-founder here. Thanks for the shout out!

That's exactly right, avoid manual infrastructure.

Someday we will all have something like Rails for infrastructure. Strong conventions around best practices.

If you follow these conventions you can avoid bespoke or manual configurations and focus solely on your app logic.

We're building Convox to advance this goal.

</comment></comment><comment><USER43> So I'd modify these a bit. We run a very large AWS infrastructure as a engineering team (no dedicated ops).

1\. Use CloudFormation only for infrastructure that largely doesn't change. Like VPC's, subnets/ internet gateways etc. Do not use it for your instances / databases etc, I can't recommend that enough, you'll get into a place where updating them is risky. We have a regional migration (like database migrations) that runs in each region we deploy to that sets up ASG, RDS etc. It allows us control over how things change. If we need to change a launch conf etc.

2\. Use auto-scaling groups in your stateless front ends that don't have really bursty loads, it isn't responsive enough for really sharp spikes (though not much is). Otherwise do your own cluster management if you can (though you should probably default to autoscaling if you can't make a strong case not to use it).

3\. Use different accounts for dev / qa / prod etc. Not just different regions. Force yourself to put in the correct automation to bootstrap yourself into a new account / region (we run in 5 regions in prod, and 3 in qa, and having automation is a lifesaver).

4\. Don't use ip addresses for things if you can help it, just create a private hosted zone in Route53 and map it that way.

5\. Use instance roles, and in dev force devs to put their credentials in a place where they get picked up by the provider chain, don't get into a place where you are copying creds everywhere, assume they'll get picked up from the environment.

6\. Don't use DynamoDB (or any non-relational store) until oyu have to (even though it is great), RDS is a great service and you should stick with it as long as you can (you can make it scale a long way with the correct architecture and bumping instance sizes is easy). IMO a relational store is more flexible than others since you (at least with postgres) get transactional guarantees on DDL operations, so it makes it easier to build in correct migration logic.

6\. If you are using cloudformation, use troposphere: [https://github.com/cloudtools/troposphere](https://github.com/cloudtools/troposphere)

7\. Understand what instances need internet access and which ones don't, so you can either give them public ips, or put in a NAT. Sometimes security teams get grumpy (for good reason) when you open up machines that don't need to be to the internet, even if its just outbound.

8\. Set up ELB logging, and pay attention to CloudTrail.

9\. We use Cloudwatch Logs, it has its warts (and its a bit expensive), but it's better than a lot of the infrastructure you see out there (we don't generally index our logs, we just need them to be able to be viewed in a browser and exported for grep). It's also easy to get started with, just make sure your date formats are correct.

10\. By default, stripe yourself across AZs if possible (and its almost always possible). Don't leave it for later, take the pain up front, you'll be happy about it later.

11\. Don't try and be multi-region if you can at first, just replicate your infrastructure into different regions (other than users / accounts etc.). People get hung up on being able to flip back and forth between regions, and its usually not necessary.

edit: Track everything in cloudwatch, everything.

<comment><USER44> Have you looked at Terraform? I have _everything_ defined (unless it doesn't work very well... which still happens as it's still under heavy development), and if it needs to be dealt with care (e.g.: core EC2 instances) I'm slowly filtering it into a separate set of units/variables, and setting the "static" infrastructure (VPC) as a downstream group, and slurping the statefile upstream as to not potentially damage anything when playing nice with deploying/redeploying EC2 instances.

</comment></comment><comment><USER45> I work in a team that uses quite a lot of AWS for various reasons beyond cost. We also use various other clouds too, depending on needs of a specific project or situation. Our experience with cloud is that it is a journey. Obviously, coupled with DevOps tooling, it'd allowed us to deal with environment requirements at the speed of software, i.e. Infrastructure as Code and all. One thing we find ourselves doing over and over is changing the infrastructure, either because requirements change, new cloud services are launched and its useful to us or simply because we find more efficient ways of running cloud resources (Trusted Advisor helps).

We'd built a tool called Liquid Sky ([https://liquidsky.singtel- labs.com](https://liquidsky.singtel-labs.com)) to help us keep track of the cost impact of the changes we make constantly. I did mention that we use cloud for reasons beyond cost, but we definitely still want to know that we're sensible and maximise cost efficiency as well, its just another (important) factor. Because we change our cloud resources so frequently, we didn't want to make it a very rigid process when dealing with the sensibilities of cloud cost. Hence, we'd built Liquid Sky in a way that gives our engineers the freedom to explore better way of running things on the cloud while keeping cost in check as well as keeping the team (including cost guardians) in the loop.

</comment><comment><USER46> Nice article, I am working in a small company (Beintoo) dice september 2015 and we use AWS here. I think is a very interesting set if products and you can build any kind of business. For sure the advices given in the article are really useful, in fact I will apply them at my job place.

About comparison with other services, I was working in Deloitte Analytics before, managing the cloud services provided by IBM Softlayer. You cannot compare them, AWS offers many more and I was not really satisfied with SoftLayer, for example I had a problem with a network upgrade they did on January 2014 and I have lost a lot of data, with poor support to restore it. Also the starting price of 25$ per month is really expensive. AWS is far more mature and interesting.

Then for my own servers I use CloudAtCost cause is cheaper but if I run a business for sure I would go with AWS. If you gain money, is not that expensive and if you stick with Amazon advices and philosophy is very reliable.

</comment><comment><USER11> I'll add one that was especially common for people coming off the year of free tier a couple years ago. I'm not sure that AWS has changed it yet.

6\. Not starting a box/instance/database and forgetting it's running until you receive the bill after your free tier expires.

<comment><USER47> I expected to see something like this generalized in the article as

6\. Not setting up billing alarms, [http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/...](http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/free- tier-alarms.html)

</comment></comment><comment><USER48> I warmly recommend the Serverless framework for building basic web applications on AWS. It handles CloudFormation details for you, but lets you customize them if needed. Not suitable for every possible app though.

</comment><comment><USER49> This might be the wrong place to ask, but I'm curious how people feel Azure stacks up to AWS? The services seem comparable (maybe even nicer), but I'm unclear how it compares on cost.

</comment><comment><USER50> I don't get all the complaints about AWS prices. I just spun up a 60 node Spark cluster with over 5TB of memory, processed 100B data records, and spent $5.50!

</comment><comment><USER51> As there's too much push to Terraform, which I personally dislike due to many opinionated features and the marketing push to cover as many services as possible and not do one thing and do it great (AWS), you can look at Bazaarvoice's CloudFormation Ruby DSL [0].

[0]: [https://github.com/bazaarvoice/cloudformation-ruby- dsl](https://github.com/bazaarvoice/cloudformation-ruby-dsl)

</comment><comment><USER52> Personally never quite got the appeal for EC2. You're basically replicating what you would be doing on physical servers anyway. The real productivity gains come from using a fully managed PaaS (Heroku, Azure Web Apps, Google App Engine, OpenShift etc.) where there is no maintenance and scaling and redundancy is taken care for you. Granted those are even more expensive but they are the only ones that provide any kind of value.

</comment><comment><USER53> I find IAM particularly difficult to use - I feel like there should be a button to create a user/group that can do only X, Y, Z. I realise policy templates get most of the way there but I still had to go and read the syntax for them because DescribeRegions wasn't in the list I needed.

I'm also not sure how to make the jump from exporting AWS_ACCESS_KEY_ID and having my instances automatically request the permissions they need - STS?

<comment><USER54> If your code is using the AWS SDK then you don't need to export an access key for your running code. Just create an EC2 Service Role in IAM with the policy you want attached to the role; then launch the instance with that role, to get automatic temporary credentials.

Refs: [http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use...](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch- role-ec2.html) [http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam- roles...](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for- amazon-ec2.html)

</comment></comment><comment><USER55> I'd like to add two more:

          1) Not giving out your access and secret keys in scripts/buckets.

          2) Always using IAM roles with your EC2

<comment><USER21> how do you avoid 1 - it seems impossible ?

<comment><USER56> IAM roles let you assign temporary credentials to machines running scripts. The machine can then hit an internal AWS URL to get the temporary credentials. Many tools know to look for these credentials by default- eg boto checks for credentials in environment variables, config files, and the machines IAM role.

<comment><USER57> And there's a few tools to emulate the metadata service locally if you need it on dev laptops which makes it use a role as if a server

</comment></comment></comment></comment><comment><USER58> What are the current ways to make creating CloudFormation templates not so painful?

<comment><USER59> You should check out troposphere ([https://github.com/cloudtools/troposphere/](https://github.com/cloudtools/troposphere/)) and stacker ([https://github.com/remind101/stacker/](https://github.com/remind101/stacker/)). I'm a maintainer of both - we try to make CF easier by catching errors earlier, and allowing you to do things like write for loops, in troposphere. stacker tries to take your troposphere templates and tie them together as totally separate stacks.

</comment></comment><comment><USER60> From the article: "The biggest problem with Auto Scaling Groups is that people assume that they are about auto scaling which they are not!"

Hmm... Then maybe the biggest problem with them is actually that they are misnamed?

</comment><comment><USER61> Has anyone tried the Trusted Advisor feature out? Have you found it worth the 3-10% on top of existing monthly usage?

<comment><USER30> If you already have a support plan, it's free. So yes, I have. Nothing useful so far, but I plan to keep checking it periodically in case I'm off my game.

</comment></comment><comment><USER62> Something major is missing:

Running Demand instances instead of Reserved

<comment><USER63> Or running Reserved instead of onDemand. It's all about use cases.

</comment></comment><comment><USER64> > _There is no reason why you should manage your infrastructure manually. It > 's unprofessional! It's a mess!_

Nonsense. Cloudformation has it's issues. It takes time to learn and implement. The templates can break, requiring the stack to be destroyed and remade. In the sample in the article, the database is in the same template as everything else - what fun that will be when an update breaks the template and you have to reapply the stack (which destroys the existing database).

Cloudformation is good, but it comes with caveats, and the idea that you should _only_ manage an AWS stack with CF is utter tripe. As with everything, it depends on your use case.

Also weird is the article's demand of using autoscaling groups to monitor single instances. Why not just monitor them directly with cloudwatch?

> _There is no reason - beside manually managed infrastructure - to not > decrease the instance size (number of machines or c3.xlarge to c3.large) if > you realize that your EC2 instances are underutilized._

This is wrong, too. Autoscaling takes time to scale up, and it scales up in stages. If you get sudden traffic, autoscaling can take too long. Again, it's about knowing your use case. Unfortunately for us, we can get sudden traffic when one of our clients does a media release and they don't tell us ahead of time, The five or so minutes it takes for instances to trigger the warning, start up a new set, and then attach these to a load balancer is too long for this particular use case, so we just have to run with a certain amount of excess capacity.

Autoscaling is awesome, but this article is _way_ too didactic in it's No True Scotsman approach.

<comment><USER65> Cloudformation can really be a harsh mistress. I feel I'm constantly discovering good reasons for not including certain sets of resources in the same templates for reasons you and others touch on. And nested stacks? You know, never say never.. Probably never again.

</comment></comment><comment><USER66> I attended aws workshop, several years ago, there I realized, that this vast ecosystem of infrastructure services require a popularisation effort of similar scale. And not just in plain English. IAM that days was not very clearly understandable, search supported only ascii and was not really documented, now that ecosystem is in order of magnitude larger and more complex. And efforts like cloudonaut's should be greatly appreciated. For the greater public good. Thank you, man!</comment>