Which language has the brightest future for replacing C: D, Go, Rust? - <AUTHOR> https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Andrei-Alexandrescu?share=1 <comment><USER2> Well, one of those things is not like the others.

Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs. To a lesser extent it may compete with Java JVM. (However at this point in time, the JVM GC technology is still far ahead of Go's GC.) If one is writing a networkish service such as REST API endpoint, Golang's combination of language featurs & quality libraries (http) is positioned very well for that. Go isn't suited for system drivers or tight loops that depend on controlling exact memory layouts. I've heard several times to think of Golang as a "DSL for networking apps" and I think it's the best succinct soundbite for that language.

That leaves D-minus-the-gc and Rust which Andrei Alexandrescu provided very reasonable analysis. I don't think either will replace C. In 1995, many predicted that Java would supplant C++ and that never happened. For the performance domains that C++ was good at (e.g. AAA games, commercial software like AutoCAD and MS Office), _it became even more entrenched._ In terms of being forced to make bets, I'd say Rust has a better chance than D because Rust has the momentum behind it that D never had.

<comment><USER3> > Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs.

I still cannot even grasp this trope. Seems like some try to apply "fake it till you make it" approach.

To me, coming from Python and Node (and a bit Ruby) development it seems as a completely opposite direction -- similar to going back to C++ or Java (where I started myself).

If not for the quirky syntax and lack of generics I would personally pose it as a replacement for the C++ itself.

Rust on the other hand seems to me to be the most promising out of these three as a systems language.

<comment><USER2> _> I still cannot even grasp this trope. Seems like some try to apply "fake it till you make it" approach._

It's not a fake trope. There are tons of blog posts from programmers describing experiences of switching from Ruby+Rails to Go, or Python+Django to Go, or Javscript+NodeJs to Go. Some defections were high profile such as Nodejs uber-contributor TJ Holowaychuk switching to Go.

Compare that to virtually zero notable stories of C++ projects switching to Go. If people are using C/C++, they very likely depend on it for the performance characteristics and therefore switching to Go to suffer a speed penalty makes no sense. On the other hand, people leaving Python/Ruby report performance gains. That's why the reality on the ground looks the way it does.

<comment><USER4>
        Compare that to virtually zero notable stories of
        C++ projects switching to Go.

A lot of projects at Google have switched from C++ to Go, and the people I know who work on them are pretty excited about working in Go. Here's a blog post by a coworker who leads the Chrome Data Compression Proxy project:

[http://matt-welsh.blogspot.co.uk/2013/08/rewriting-large-pro...](http://matt- welsh.blogspot.co.uk/2013/08/rewriting-large-production-system-in-go.html)

<comment><USER2> Thanks for the example. I think your coworkers' rewrite further reinforces the "sweet spot" for Go.

The transcoding was left as C++ but the other stuff including the networking was rewritten in Go. That makes sense to me because transcoding is performance intensive and cpu-bound instead of io-bound. (E.g. CPUs pegged at 100% while bytes being read at a slow 10MB/sec.) In other words, if people tried to rewrite ffmpeg in Golang, a conversion job such as avi to mp4 would run slower.

If Google's internal cpu-bound projects switched from C++ to Golang, that would be a very interesting data point. In other words, I don't expect Google would switch their machine-learning algorithms scanning petabytes of data from C++ to Go (or create greenfield machine learning projects using Go instead of C++).

</comment></comment></comment></comment></comment><comment><USER5> > Given C++'s age, I'll assume in the following that the question also puts > C++ alongside with C as a target for replacement.

Yes, C++ is old, but it has really stayed with the times in an impressive way. The so-called "Modern C++" that started with C++11 is a significantly different way of writing C++. All the things that made C++ infamously challenging and allowed inexperienced developers to leak memory and cause crashes, are, for the _most_ part, no longer in the normal C++ workflow.

And all the rage about functional programming, passing around functions as values, writing closures that capture and encapsulate their surrounding values, using map, filter, reduce algorithms, relying on type inference, forgetting about pointer deletion and manual memory management and avoiding the access out of bounds memory on iterations -- that is all normal C++ now.

If anything has or will successfully replace C++, it is going to be C++ itself. The standards committee and community are doing an extraordinary job of keeping the language current while maintaining its great reputation for speed.

<comment><USER6> C++11 in no way solves the fundamental problem of C++. C++ is too big and has too much baggage. There are too many corner cases and oddball stuff to deal with. Being a good C++ developer requires unnecessary amounts of training.

C++11 can't remove what is already there and so one just keeps piling on more stuff increasing the complexity.

I am actually sad C++11 happened because it keeps alive a language that should have died years ago.

I've worked years on projects where so many of the fundamental problems can be traced back to the usage of C++. Huge amount of legacy code which can't safely be refactored because C++ is just too complex a language for a refactoring tool to be able to deal with properly. Insane compile times. Odd hard to track down problems from static initialization and deinitialization. Templates are impossible to use in a sane way because they mix so poorly with regular OOP in C++ and increase compile times too much to be practical.

Move a project like that gradually away from C++ is a huge undertaking and nobody is going to support it as long as C++ keeps updating self to not be completely behind the times.

<comment><USER5> >There are too many corner cases and oddball stuff to deal with.

It seems like all the langauges I've used, from objective-c to swift and Clojure require you to keep certain aspects of the language in mind for certain situations that don't on the surface seem obvious. Purity in any language is quite rare.

In the case of C++, it is possible to ignore much of that old baggage most or maybe even all of the time if you write new code using new features. I agree that those maintaining much older codebases are going to have a rough time, but is not an uncommon problem in many languages.

Also, even in a so-called "better" language you can run into massive refactoring projects with older code once you choose to adopt new libraries and tools. As Bjarne says, C++11 is much better, C++14 will be even better, and C++17 is further going to be better... frankly, this is a good path for any language to be on.

<comment><USER6> I don't think purity is the problem. I just think simplicity has value. It makes it possible to keep most of a language in your head. It makes it possible for anybody on your team to have a chance of understanding your code.

There was a time I tried to embrace modern C++. Problem is C++ is so big that there will always be lots of people who don't understand the code you are writing. I used to have tech talks to explain concepts like C++ concepts, models and how it relates to STL containers, iterators etc. But ultimately all these efforts is just putting bandaid on a shitty language.

The whole point of programming languages is so people can exchange code and understand each others code. C++ is epic fail in this area.

While Objective-C is also a kind of old and crufty language, it is infinitely simpler than C++.

Maintaining old codebases in anything other than C++ is much simpler for many reasons. Refactoring tools in languages like Java and C# actually works. Refactoring in Ruby or Python is simpler because they more naturally decouple due to their dynamic typing.

Refactoring C++ code is hell on earth because the refactoring tool has to be able to understand macros, C++ templates etc. Any changes to a class interface even private methods or variables requires recompile of all files using that class. Which means doing lots of changes means recompile of lots of files. Which sucks in a large project when C++ is terribly slow at compilation to begin with.

Compare with a language like Go. The syntax is so much more sane that you can actually write simple refactoring tools yourself easily. No way in hell you can do that with C++.

No matter what Bjarne does with C++, they will still be stuck with macros, a fiendishly complicated template system, static initialization and deinitialization mess. As long as you need to remain backwards compatible you are stuck with a lot of awful stuff.

<comment><USER5> >But ultimately all these efforts is just putting bandaid on a shitty language.

Well, that's a highly subjective opinion. It sounds like C++ doesn't work for _you_ but I still find it a fascinating and enjoyable language to work in. There are drawbacks with any language, and I guess the drawbacks you find for yourself in C++ are your business.

</comment></comment></comment></comment></comment><comment><USER7> First and foremost: this is a good and fair post.

I disagree with Alexanders (regular) narrative that Rust puts a lot of estate into safe memory handling. Rusts memory management features may seem daunting at first, but they make advanced things (like type-system assisted data sharing) a breeze. So, while the whole "let's talk about data"-aspect of the language _does_ take a lot of estate, it goes far beyond "let's talk about memory".

I agree though that this is a property that comes rather late in learning the language and we still struggle to communicate that easily.

</comment><comment><USER8> Replacing C? Not gonna happen anytime soon... I think C is a beautiful language and is probably one of the languages with more lines of code in the history, hugely used even today and the still the best for a good amount o scenarios.

Long live C!

<comment><USER6> From what I understand Cobol and Fortran still leads in number of lines. So much scientific software: weather simulations, military simulations is still in Fortran and Cobol runs at the core of so many banks. In my home country Norway you used to be able to download the code that was used to calculate your taxes (might still be possible but haven't tried in years). That code was all Cobol. So I suspect a lot of government stuff is also Cobol.

I am quite fond of C as well, but you know there are quite a lot of other nice languages out there as well. Since I started writing Swift, e.g. I haven't felt much need for C for anything anymore.

A problem for me jumping to C#, Java etc is that those are managed languages with very different set of tools and thinking. As a long time C/C++ developer, Swift feels much more natural as the tools, compile process and thinking is much more similar.

And Go has a very similar feel to C. When you read Go code it has much of the same simplicity and straightforwardness about it as C code. Even if I don't write much Go code I often read Go code to understand how things work, e.g. HTTP code, encryption stuff etc. Much easier to read the Go code than the C code or anything else really.

<comment><USER8> How does Swift do for embedded systems? Most of the processors in the world are not the usual PC, they are embedded systems. 99% of the embedded systems shop use C! There are still loads of 8 bits microcontrollers being sold every day and they aren't going anywhere anytime soon.

But I do agree with you, I am a web developer today and use Python, C doesn't fit too well in this space.

<comment><USER6> I've worked AVR microprocessors (used in Arduino) and I found that for as small programs as I would write on a micro controller even assembly programming works. But C is definitely a good fit. Since you need effortless access to many low level details I think C is probably the best language for writing micro controller software. Of course as the software gets larger I guess it start making more sense to switch to something like Swift or Rust.

The right tool for the job right? C is the right choice in many cases. It is just that C/C++ has been used for a lot more jobs than they are the right choice for.

</comment></comment></comment></comment><comment><USER9> What a fantastic, thoughtful post. If anyone is skipping to the comments here based on the title, you should read the article, not least because it's by Andrei Alexandrescu.

<comment><USER10> D is my favorite. My problem is lack of IDEs and I do not count Visual D as one of them since it requires Visual Studio which is heavy and not crossplatform.. If they could go with Visual Studio Code (when it matures) or KomodoEdit which are cross-platform and free (bias on KomodoEdit) I would be all for that.

Until then I put my bet on Mono-D and DDT.

In any case, this month is the D month for me. Enough is enough with C++ and I am thankful to them because they made an amazing replacement.

<comment><USER11> Visual Studio 2015 Community edition it's far more lightweight that for example Eclipse.

I just re-attach to D for doing some stuff, and I found that DUB and VisualD just works very fine. And I'm a guy that in 75% of my time running on a GNU/Linux...

</comment></comment></comment><comment><USER12> I love to do C programming. C++ in comparison, I don't enjoy at all. I think it's the syntax. C# and VB.net are fun, and fast to work in. Obviously just my opinions of course. Java is fun and fast.

With C and even Objective-C, I have to plan everything out, and finely craft the code. It's meant to be closely examined and optimized and perfected. That's what makes it rock-solid in my experience.

I don't have type-related or buffer or memory related issues since its part of developing in the language. Things like Heartbleed are interesting, because obviously the guy was overworked and didn't spend enough time with the code before checking it in.

I view those types of issues as 'check-in irresponsibility' and it can occur with any language, not just C. My answer would be 'None of the above'.

</comment><comment><USER13> Why does anything need to replace C? It's been fine for years and still does exactly what it needs to do.

<comment><USER14> You're right. It keeps on giving us heartbleed, slammer, sasser, kernel null check eliding holes, and literally thousands upon thousands of other memory exploiting, remote executing, security breaking bugs.

But I'm sure, Real Soon Now(TM), if teams just adopt (best practices / better libraries / better code reviews / better static analysis tools / better testing) all those problems will be solved and C will be a great language to keep using.

After all, saving a few extra CPU cycles is totally worth breaking all SSL encryption and leaking private keys, quite literally putting the security of EVERY SINGLE FUCKING HUMAN WHO HAS EVER TOUCHED THE INTERNET in jeopardy.

So sure, let's just keep using C. It's fine, why change anything amirite?

(Sarcasm aside: In the general case it is not possible for humans to write security-critical code in C. So far the history of the internet has proven me 100% correct.)

<comment><USER15> What other language would someone use to write a kernel or driver? Even if you use a higher-level language for most of the logic you'll likely want the core to be C -- amazing considering the language is nearly 40 years old. C is, to me, a systems programming language. Writing code that handles any significant amount of user input in the language is a mistake I believe. Note that this doesn't include C++ which has more modern constructs.

<comment><USER16> You might be surprised that NeXTStep used Objective-C for device drivers in the kernel.

<comment><USER6> That is pretty cool. Shows some of the versatility of Objective-C. I was also surprised that a low level API like Metal also uses Objective-C.

</comment></comment></comment></comment></comment><comment><USER17> I'd bet my money that C will outlive them all.

<comment><USER18> Yes. C has the lowest abstraction depth without going into platform-specific details like asm. LLVM is the only thing that could compete with C on that level.

<comment><USER19> You probably know already, but just for anyone that doesn't, Rust uses LLVM to compile its machine code.

<comment><USER18> Properties of an language are not necessarily inherited when compiled. LLVM Code is not bound to Rust's memory access restrictions.

<comment><USER20> The Rust developers specifically tailor the compiler to generate LLVM IR that resembles Clang's generated LLVM IR.

</comment></comment></comment></comment></comment><comment><USER10> It would be more accurate to say C++ and not C. C is here to stay.

But the biggest question is not replacement but interoperability. Can I call Rust code from Go? Can I call Go from Rust?

<comment><USER20>
      >  Can I call Rust code from Go?

Yep. Rust code can easily expose a C ABI, so any language that can call into C (which is every language) can potentially call into Rust.

      > Can I call Go from Rust?

Go is working on exposing the ability to compile standalone libraries that can be called from other languages. Support was spotty last I looked, but it should be interesting to watch going forward.

</comment></comment><comment><USER21> If Rust's syntax would be more close to other languages it would be the dealbreaker.

I mean most simple things are easy to read. But once in a while you stumble around code that nobody will understand if not every single character is well documented.

Still somehow I love it.

</comment><comment><USER22> Clojure is the new C [http://www.infoq.com/presentations/clojure-c](http://www.infoq.com/presentations/clojure-c)

<comment><USER23> Wow, that's probably one of the last things I would have thought of. I look forward to listening to that.

<comment><USER24> I agree when Clojure gets rid of the JVM dependency. The Java ecosystem is nice but the annoying startup time of Clojure apps and the strange error messages of the Clojure compiler are reasons why Nim has become my favorite.

</comment></comment></comment><comment><USER25> No language will replace C, but all of those mentioned will eat some of its cake. Its usage will shrink, but C is here to stay.

D is what C++ should have been. It had some traction in mid-2000s but the Tango vs. Phobos debacle killed it.

Go is the most serious of the three languages mentioned. It has the momentum, solid community, solid tooling, and corporate backing. It's well suited for networked services, but it is not replacement for C.

I'm not so sure about Rust. Unlike D and Go, Rust can replace C (in theory), but I don't think that will happen. Rust has a feel of a hobbyist language in perpetual alpha.

<comment><USER11> > but the Tango vs. Phobos debacle killed it. It was D1 lang.

You should know now that D2 have single standard lib, the official compiler front end is wrote on D, and open source. Plus there is LDC and GDC implementations.

<comment><USER25> I know, but it missed an opportunity to go big.

In early 2000s, Microsoft basically told Win32 API developers to either migrate to .NET or to go fuck themselves. There was a lot of FUD flying around. At one point, people were wondering will the new Visual Studio ship with C/C++ compiler.

In it's quest to promote .NET, Microsoft even got Borland to kill itself by jumping on the .NET train. The days of native Windows development were over and the best alternative to MS stack, Borland with its Delphi, decided to commit suicide.

That was the chance for D to shine. I was among the developers looking for non-MS solution for native Windows development and D was my favorite, but the Tango vs. Phobos thing killed it for me.

Like many developers at that time, I left Windows for the Web development. If D was then what is now, I would stay with Windows a bit longer than I did.

</comment></comment></comment><comment><USER26> The whole article is a little spurious. None of the languages mentioned (C, C++, D, Go, Rust) target exactly the same space (even though they all overlap).

Go and Rust in particular have been designed with very specific clients in mind (replacing Google's use of Python for server-side work and safety- paranoid multi-threading for Mozilla's Servo, respectively).

Rust is the only new language mentioned that resembles C in its capabilities but then again: C++ resembles C in (theoretical) capabilities but never de- throned C (mostly because when you use C++ like C, you might as well use C).

</comment><comment><USER27> > Reading any amount of Rust code evokes the joke "friends don't let friends > skip leg day" and the comic imagery.

That could not have been more graphically enlightening.

</comment><comment><USER28> Nim for sure. Compiles to C and it's awesome.

<comment><USER29> The language known also as n_i_m and NiM?

<comment><USER24> I was involved in programming from the very beginning (the time of KIM-1) and I learned many programming languages, the major ones (C, C++, Java, Ada, Perl, Python, ...) and also very exotic ones (Assembler, APL, Fortran, Prolog, Lisp, ...). No language was more productive for me than Nim. Ever. It's the ideal "mix" of C, Python and Lisp with C++ native performance. Nim is really nice. I wonder why it is still barely known.

[http://nim-lang.org](http://nim-lang.org)

[http://hookrace.net/blog/what-is-special-about- nim/](http://hookrace.net/blog/what-is-special-about-nim/)

Uses Cases:

[https://github.com/nim-lang/Nim/wiki/Nim-use-cases](https://github.com/nim- lang/Nim/wiki/Nim-use-cases)

Note that meanwhile there is also NimScript, an interpreter for a subset of Nim, which can be used for shell scripts.

Nim for scientific computing:

[http://rnduja.github.io/2015/10/21/scientific- nim/](http://rnduja.github.io/2015/10/21/scientific-nim/)

> The language known also as n_i_m and NiM?

[http://blog.codinghorror.com/the-case-for-case- insensitivity...](http://blog.codinghorror.com/the-case-for-case- insensitivity/)

I have no problem with that because this way everyone can use his favorite notation. The only thing that strongly reject are strong spaces. That was a silly idea and should be removed instantly.

<comment><USER30> What do you think about Julia?

<comment><USER24> I have barely touched Julia and I am impressed by the performance. It could become a real competitor to R.

Nim could also play a significant role because its syntax is similar to Python, and because NumPy is a Python API which is very prominent among scientists. However someone has yet to write a Nim library similar to NumPy.

Nim has the advantage of zero overhead to C, and it compiles to C which makes Nim an interesting option for super computing.

<comment><USER29> > Nim has the advantage of zero overhead to C,

Untrue. Nim requires the use of a garbage collector.

<comment><USER24> No. Counter example from [http://learnxinyminutes.com/docs/nim/](http://learnxinyminutes.com/docs/nim/):

      # Because Nim compiles to C, FFI is easy:

      proc strcmp(a, b: cstring): cint {.importc: "strcmp", nodecl.}

      let cmp = strcmp("C?", "Easy!")

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Different languages will probably replace different parts of C usage. I suspect Go will replace C/C++ for high performance server side stuff like databases and various server software. E.g. I've seen a bitcoin server being written in Go. That is the sort of stuff that makes sense for Go I think.

However C is often used for writing libraries that can be used for many languages. Think about OpenSSL e.g. I doubt C was chosen due to its credentials as a secure language. Rather this is a liability for C/C++ in many areas.

I think Rust will replace this. Actually I think Swift will be fighting with Rust over some of the the same territory. They both got the same advantage of not requiring a garbage collector and thus can be used to write libraries to be used by any language through a C-API.

While Rust might have an edge language wise, Swift might be just good enough. That matters because we are using C/C++ not so much due to the quality of those languages but due to a combination of their feature set and existing momentum.

Swift is more or less guaranteed to get big as it is replacing Objective-C for iOS development rapidly. That will create a large user base for it quickly. This will only accelerate when Swift goes open source and can be used on more platforms.

Both D and Rust have a bit of a chicken and egg problem. People aren't going to use those languages if people don't believe they have a future. They wont have a future if people don't believe they have a future. Rust is novel and cool enough in a geek perspective that I think it will gain enough momentum to get some presence. D has been around for a long time without that happening so there is no reason to believe it will happen now.

Swift has the chicken and egg problem solved. For writing something like OpenSSL it would take away many potential problems. No accidentally not executed code due to not using curly braces for if statements. No exploitable buffer or integer overflows. No accidentally uninitialized variables. No accidental switch-case fall through. No unintentional type conversions. A whole host of memory bugs gone.

<comment><USER31> On OSes written in C, C benefits from OS ABI == C ABI, but it wasn't always like that.

</comment></comment><comment><USER32> Depressing to read. Somehow I can not find a language I really like :-(

<comment><USER33> I miss Delphi more and more. The language is ok-ish but when it comes to rapid Gui development it still runs cires around everything else.

</comment></comment><comment><USER34> For me the minimalism of the Go language, the quick learning curve, the great standard library, and the ease of deployment make it a great choice. I hardly ever need to code things in low level assembly, but I do need to revisit old code frequently. The explicitness of Go makes it easy to work on coded you have not touched in 6 months. I have not looked at D, and Rust is still pretty new. I may give Rust a try in the future if I can find a project for it and I have some time to learn it.

</comment><comment><USER35> c++. Its not going away.

<comment><USER36> The level of verbosity in modern C++ is almost approaching Java levels these days. I could see a simpler language gain favour.

<comment><USER37> The beauty of C++ is that you can define an arbitrarily small subset of the standard that work as simpler language of its own!

Too bad not two projects can agree _which_ subset.

<comment><USER38> Sounds like someone needs to rigorously define a good subset then write a tool to verify that a program uses only that subset.

<comment><USER39> As if by magic....

[https://isocpp.org/blog/2015/09/bjarne-stroustrup- announces-...](https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces- cpp-core-guidelines)

<comment><USER40> Wow, that's huge. It's what everybody's doing anyway, but being standardized with big names and heavy hitters behind it makes it much easier to advocate and argue for.

Such an effort would be so much easier to advocate for in a C++ shop, and more importantly, very difficult to argue against.

This deserves a proper HN discussion. I've resubmitted it, it missed the front page the first time around:

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

(sorry for the karma stealing, lucozade totally deserves the karma if my resubmission takes off)

</comment></comment></comment></comment></comment></comment><comment><USER41> While the post is fantastic in showing the pros/cons of the other languages, it doesn't talk about the advantages of C, advantages to some people at least. Here's Linus on replacing C: [https://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s](https://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s)

</comment><comment><USER42> I think that C is completely fine; Language is relatively simple, and so can be easily used/implemented anywhere. Any dynamic parts and GarbageCollection can be provided by C libraries.

By using source-to-source compilers, C is a good target language.

From this standpoint, we can treat C as a "cross-architecture assembly platform".

Simplicity is beautiful!

<comment><USER24> Yes, simplicity is beautiful but C is not state of the art anymore. In comparison to modern languages C is merely a high level assembler. Why fiddle with C when you can use modern languages which can compile to C anyway?

<comment><USER42> high level assembler - exactly!

</comment></comment></comment><comment><USER43> If the next C standard were to introduce something like try/finally/throw to replace prehistoric libc-based setjmp/longjmp, it would shrink the gap between it and other languages, well, I'd say roughly by half.

<comment><USER44> It seems unlikely that would happen. What would be the semantics of stack unwinding? C doesn't have destructors, so (as with longjmp) you end up losing track of memory allocations which were pointed to by the stack.

I do offer my own pet wish for C though: Official support for __attribute__((cleanup)). GCC and CLANG support it.

<comment><USER43> The semantics would be nothing but executing the finally block. As a rule C programs do only what is explicitly coded. No high-level programming language behind the scenes stuff.

</comment></comment></comment><comment><USER45> Amongst all the technical differences, following are some of the factors from a team-lead/architect p.o.v:

1) What is the ecosystem now? If it is not good, does it look like it will improve in next X time or so?

       1.1) What are the production ready libraries right now?
       1.2) Who are the maintainers? Who is backing them?
       1.3) How approachable is the community?
       1.4) Are the current pain points are being worked at and at appropriate speed?
       1.5) How is the tooling scene?

2) What is the overhead for large codebases? e.g factors = [simplicity, deployability, testability, code-review, refactorability, learnability]

3) How hard/easy it is to wrap C/C++ code/libs if we ever need? Will there be any performance impact?

4) Does it look like more CPU bound code will be added looking at the product roadmap?

We are a python shop. As long as it was network IO centric we were ok. However due addition of features, the CPU bound code has increased and we clearly see the limitations of Python. This has led to find the replacement language. Since we are reviewing now the 'X time' in #1 is '1 year'. For others the tolerance may vary.

As for #2: Code review has an additional overhead due to Python's dynamic nature. Also we need to write additional unit testcases. A language which "prevents" basic issues (not going into 'how') has less overhead on the team.

#3: From what I know, go does not do well here in terms of performance. We deal with lot of 3rd party APIs e.g using VMware APIs which are in C and are called in the main loop. Also evaluation of this point helps us to see if any shortcoming in the current libraries can be augmented by wrapping existing C/C++ libs. Rust & D are better I suppose.

refactorability: GC'ed languages inherently has an advantage (for large codebases). Counter examples welcome.

learnability: Rust suffers here most. This is a point which makes it hard for Rust to get introduced and even though I may have patience to stick with it others may not and drives down the adoption. On most occasions, other teams also need to be convinced for any meaningful transition.

Testability (i.e. unit tests): Python is really good at this. This is not a point for the testing tools but more for language features. I find dependency injection in Rust really hardest right now (or may be I might have missed something)

#4 is true in our case.

#1 (libraries/tools): Go is ahead I think in terms of production ready libs.

#1 (community aspect): Go & Rust are better here than D (right now) even though the founder of D is prolific. Note that when championing a language inside a company is concerned perceptions matter a lot. Here I think D suffers a bit in my case.

Right now I am in wait-and-watch mode but leaning towards Rust.

(edited: formatting issues)

<comment><USER46> One advantage of D compared to the others is C++ integration. It can actually do it partially, whereas other languages just fall back to a C-ABI layer in between.

</comment></comment><comment><USER47> C

</comment><comment><USER48> If C++ couldn't do it, D won't. They are of the same ilk.

Go kinda is already, but is too sucky on too many levels to really break through.

Rust is still alpha and seems to be going backwards at times, but looks like a strong contender.

Assuming Go fixes its many problems, and Rust is eventually delivered, I think they will both have a strong role to play, Go in the networking/systems space, Rust in the large scale app development space (like making a browser).

But C will still be around.

<comment><USER10> Go is not sucky. It is fantastic at what it does. I really see it as a valid replacement for all sucky frameworks like:

Django/Rails Sinatra and so on.

These frameworks do injustice to their languages :

Rails hurts Ruby, Django hurts Python, Sinatra hurts Javascript.

JavaScript has a lot to offer but in the distant future. An even then it relies on slaves building pyramids.

<comment><USER48> > Go is not sucky. It is fantastic at what it does.

Go _is_ fantastic at what it does well, which is lightweight concurrency (with a synchronous api), something that no other compiled, imperative language offers.

But I haven't spoken to a single Go developer (and I've spoken to a few) who don't hesitate to tell me how sucky it is in many, many other ways. I've heard the phrase "I'm really starting to hate Go" more than once or twice.</comment></comment></comment>


Jaws: The Serverless Framework - <AUTHOR> https://github.com/jaws-framework/JAWS/blob/master/README.md <comment><USER2> Of interest:

The following real life scenario below portrays an administrative API layer that runs in EC2, and how it compares to what the raw hardware costs would be in Lambda. It purposefully excludes anything to do with requests (CloudFront+ELB for EC2 and API Gateway for Labmda).

EC2 scenario: 2 c3.large instances, general purpose 15GB SSD (need two for HA, span AZs) 1 Yr All upfront reserved pricing on both instances

Lambda scenario: 1042 memory size Workload running on EC2: 16000 requests a day to an endpt. 200 ms ave = 3200000 ms total

3200000 / 100 ms = 32000 segments of 100 ms

EC2 Cost: 1084(yr)/365 = $2.96986301369863/day

Lambda Cost: 32000 * 0.000001667 = $0.053344/day

The cost difference is so large because this workload is not a very high EC2 utilization scenario. We need extra servers for multi AZ HA and to handle bursts. Lambda handles both of these for you.

This also does not include the huge costs savings of no server management (security patches etc) that go into EC2 or Docker containers.

<comment><USER3> Using two c3.large instances to serve 16,000 requests a day (~11 requests a minute) is akin to using a muscle car to commute a quarter mile - you're vastly over-provisioned for such a simple workload.

This kind of workload could easily be handled by a pair of t2.micro instances. This would cut your costs for dedicated servers to around $0.40 a day.

Plus, you could then take advantage of persistent in-process memory caches and warm services, helping to speed up your responses even further.

Using tools like Lambda come with a number of advantages, but you give up a lot of control at the same time. Perhaps this isn't a problem for most side projects, but for business critical software I'd be very leery of handing that much control over to someone as uncommunicative as Amazon.

<comment><USER2> "The cost difference is so large because this workload is not a very high EC2 utilization scenario. We need extra servers for multi AZ HA and to handle bursts."

<comment><USER3> The $0.40 cost per day I calculated includes multi-AZ HA, and your bursts would have to be fairly significant to overwhelm two t2 instances which are accumulating CPU credits 95% of the time - say around 600 requests per minute for a few hours.

Of course, this is all conjecture since I can't actually view your workloads, but we've been performing this exercise for our own services, and the t2 series of servers is remarkably capable: especially given their cost. The original administrators thought (or were lead to believe) that we really needed the raw horsepower that c*.large+ instances offer... and they didn't in most cases.

Routers, crud API wrappers, even some disk persistance applications all qualify as "non-CPU intensive".

</comment></comment></comment></comment><comment><USER4> A neat idea, but the resultant vendor lock-in here worries me. I've heard horror stories of the amount of effort required to move away from PaaS platforms like Heroku (I believe Genius is one such tale) due to architecture- specific components like jobs, but this seems to take that reliance to a whole new, all-inconclusive level.

This might be neat or a quick weekend or hackathon project where you just want to Get Shit Done, but I can't imagine anyone ever committing fully to the platform and having no second thoughts.

An open architecture built on this sort of idea would be nifty, but tools like Docker have almost reduced the sysadmin components for a lot of simple projects to something that's not too far from this anyhow, from an ease of use perspective.

<comment><USER5> Lambda functions are just small Node scripts wrapped up in a Docker container and then executed on a custom scheduler. I don't think it would be too difficult to port to another platform.

<comment><USER6> And Java classes.

</comment></comment></comment><comment><USER7> I am slightly confused.

Doesnt "serverless" and "using Amazon Web Services" contradict each other?

<comment><USER2> By "Serverless" we mean the developer does not have to think about servers. They exist, but Amazon manages them.

Instead, the developers deals only with Lambda, an event-driven compute resource. You upload your code and it runs when triggered, scaling horizontally and massively, out-of-the-box.

The workflow rocks because it's endpoint/function isolation, not just application isolation. Every piece of logic is in its own container. Best of all, you only get charged when that code is run (!!!).

</comment></comment><comment><USER2> JAWS Slides From Re:Invent:

[http://www.slideshare.net/AmazonWebServices/dvo209-jaws-a- sc...](http://www.slideshare.net/AmazonWebServices/dvo209-jaws-a-scalable- serverless-framework)

<comment><USER8> Slideshare is horrible, can you please put those slides on the GitHub repo or a dedicated repo? Thanks.</comment></comment>


Ask HN: What's with companies making mid-levels interview seniors and leads? - <AUTHOR> Seems backwards to me. <comment><USER2> I can't speak to your specifics, but I've interviewed people that would be my manager before. While I didn't have the final hiring decision, my input was valued because the person hiring them was C-level, and not as knowledgeable about the function this person would be leading as I was in many ways, both because of their skillset/experience, as well as the level of interaction they had with the team.

Outside of title inflation concerns where it may be useful, it's really an opportunity to get additional valuable perspectives.

</comment><comment><USER3> Senior / lead at one company is not necessary on the same level as one at another. Rampant title inflation over the past decade has made this especially true. I think I got my first "senior" title 2 years out of school! Also, culture fit...

</comment><comment><USER4> You will have to work with those people. If you don't get along, you won't be effective.</comment>


A Wisconsin bank wants coins, and it pays above face value for them - <AUTHOR> https://www.jsonline.com/story/news/local/2020/07/17/milwaukee-area-bank-buy-coins-above-face-value-during-coin-shortage/5458324002/ <comment><USER2> Here in Michigan merchants tell me their bank limits the amount of coins they can get on a daily basis. Seems like it would be a pretty inexpensive marketing tactic to get new business clients.

<comment><AUTHOR> Interesting point, wonder if there is friction to this. From their website, [https://csb.bank/coinbuyback.html](https://csb.bank/coinbuyback.html), it seems simple but the transaction could be a hassle if there's more to this.

</comment></comment><comment><USER3> This is a sign of an impending run on precious metals.</comment>


Free online WebAssembly Studio - <AUTHOR> https://webassembly.studio/ <comment><USER2> And Fastly Terrarium, that compiles WASM code to native code, and runs it server-side [https://wasm.fastlylabs.com/](https://wasm.fastlylabs.com/)

<comment><USER3> Hello Frank, big fan of libsodium & your other work. Are you involved with Terrarium?

Is this wasm compiled with turboFan in V8?</comment></comment>


Ask HN: What happened to CloseTabs chrome extension? - <AUTHOR> I just noticed CloseTabs extension was removed from my Chrome and I can no longer find it in Chrome Web Store either. Was it removed by Google? <comment><AUTHOR> Here is the url when it was available [https://chrome.google.com/extensions/detail/gadafnnkijfmbbme...](https://chrome.google.com/extensions/detail/gadafnnkijfmbbmeielphlapddbmgbgo?hl=en)</comment>


You Don't Want Your Privacy: Disney and the Meat Space Data Race - <AUTHOR> http://gigaom.com/2014/01/18/you-dont-want-your-privacy-disney-and-the-meat-space-data-race

<comment><USER2> I tried to install a light flash app (like the author) and when I saw how much privileges it was asking for, I passed on the opportunity. Out of curiousity I googled to see why a flash app might need all these permissions and it became apparent that some of these apps are doing all kinds of things that have nothing to do with the utility of the app.

I don't think users are that fond of giving away their data when they actually are aware of how it is being used. Maybe in the Disney setting, users aren't thinking about any downsides.</comment>


Learn You a Haskell for Great Good - <AUTHOR> http://learnyouahaskell.com/chapters <comment><USER4> This is an amazing book. I highly recommend it as the first Haskell book you read. After it, you can check out Real World Haskell.

To elaborate on why you shouldn't read (at least the online version of) Real World Haskell first: It has a lot of important topics that it covers that LYAH does not cover (like how to use cabal their package manager). But, it's not as good of a tutorial on the language and functional programming. It glosses over very complex topics, goes into a lot of depth on details that are not so important and worst of all, gives you some exercises that you aren't capable of answering yet. I tried learning Haskell three times from that book and gave up because it just killed my confidence.

Then I discovered LYAH. It explains things very simply and at a very good pace. If you want to learn Haskell and/or functional programming, I can't recommend it more. Imagine one of the Head First books without all the corny. The only thing I wish it had was exercises.

<comment><USER5> I started reading the online version, enjoyed it so much, I went ahead and boug ht the treeware version. And it's _awesome_.

I felt so loved as a customer of No Starch Press. They sent me the book, let me download the ebook in three free formats (no DRM), plus I got a bunch of freebie stickers.

The book itself is also quite remarkable to me in that I can read it and understand Haskell without needing a computer. I am used to reading mathematics books, and while I don't think Haskell is a programming language for all mathematicians as is so often advertised, the language does have a certain appeal to it in that you can treat its programs as abstract exercises that you can do independently of a machine. The statelessness of the whole thing doesn't need me typing stuff into a machine to see what a particular line of code. This makes it great for offline reading, away from the computer.

So yeah, get the treeware version. Support your favourite authors. :-)

<comment><USER6> =/ I never got freebie stickers from No Starch Press (probably cause I buy it through amazon). Their book quality is amazing, the paper and cover are very nice quality (unlike other publishers >=( ), I bought the learn you some erlang for great good, art of R programming, and the eloquent javascript.

</comment></comment></comment><comment><USER7> What I find confusing with Haskell is that the keywords don't seem to be consistent with the concepts they're meant to express. As someone new to Haskell I learnt that the `class` keyword doesn't express the object-oriented concept of class, but the concept of type class, which is different. Fair enough. What about declaring types then? That must be `type`, right? Nope, `type` is for creating type aliases. OK, surely that must be `newtype` then? Wrong again, `newtype` is also for declaring aliases. All right, to declare a new type, you don't use `newtype` nor `type` you use `data`. But be careful, the part that has the `data` keyword is still called a type constructor, whereas the part that does not have the `data` keyword is called a data constructor.

OK so let's recap, you create a new type with `data`, which is formed of a type constructor that starts with the keyword `data` and a data constructor which doesn't start with `data`. To create aliases you use `type` and `newtype` and to create type classes you use `class`.

Now how do you call the type class of things that can be mapped over? Surely that must be something like `mappable`?

<comment><USER8> The designers of Haskell (and Haskell is one of the few successful design-by- committee languages,) were not doing things "your way" (where I assume _you_ are a working programmer, with knowledge of some or even many traditional imperative languages.)

They were PL researchers. Used to ML, Common Lisp, Ada, and, most importantly, Mathematics and Category and Type Theory.

`data` introduces an _algebraic data type_ , so it makes sense to use data as a keyword. `type` and `newtype`, on the other hand, are programmer's conveniences: both carry no runtime cost, they are not actually part of the semantics of the backend language.

`map` is a function that's really just a specialization of `fmap`. Now, my category theory is a bit weak, but if I'm thinking correctly here, `fmap f` is an endofunctor in the category of _functors_ , and so it makes perfect sense to call "mappable" Functor. There's also "Traversable," which works pretty much like a fully-fledged "mappable" with all extras, but also requires a Functor instance.

Keywords, and idiosyncrasies of a syntactic nature are really just superficial. The actual elegance of the language is its type system. (The actual warts of the language are, for the most part, also in the type system; records for example.) The latter criticism about `mappable` is really just due to the fact that you haven't gotten used to the underlying theory (and I don't blame you, it's hard.) But getting used to it can be rewarding. I'm not saying it's going to make you a better programmer (I'm not necessarily of that opinion,) but it's rewarding in its own right.

Oh, and the difference between data constructors, type names, and, later, kind names (with promotion, since 7.4,) _can_ be confusing. I sometimes find it an oversight that they are not distinguished syntactically, I think that would greatly help most newbies, and sometimes even make things easier to read and understand for veterans, too.

<comment><USER9> Huge mistake on their part, typical of math people. High level programming languages have to be as close as possible to human languages (English) not to some obscure mathematical concepts and notation that most people don't care about. Actually math notation itself (cryptic, inconsistent, ambiguous) is a horrible result of math people's communication handicap and ineptitude.

<comment><USER10> No. The math notation that is used across all branches of mathematics is consistent and unambiguous (the notation of formal logic, naive set theory, etc). The only ambiguity typically comes from traversing different branches of the discipline, which is inevitable considering how many branches there are and how deep they go.

Furthermore, mathematics is all about communication. The language of mathematics exists to codify concepts so that they can be talked about concisely. Being able to say 'group' instead of 'set with an associative binary operation with identities' is essential if you want to be able to build on top of that concept without taking an hour to read one theorem.

The handicap in communication isn't on the mathematics end, it's on your end. You seem to expect them to be able to explain structures to you that took years of work to build by using the same language that you use to talk about sports or social events. The reality is that you are not the target audience of their communication, and they are okay with that. You should be too.

The weirdest assertion that you made is that high-level programming languages ought to be as close as possible to human languages. The two categories of languages exist to communicate fundamentally and widely different groups of concepts. Words represent categories of analogous concepts, and the relevant categories in human life are nothing like the relevant categories in programming. In Haskell, 'functor', 'applicative functor', and 'monad' are highly relevant categories. They pop up everywhere and can be leveraged with great benefit. In human life these concepts are far less common, and thus do not merit words in the common vernacular. Were we to use a programming language modeled on English, we would miss the benefit of these abstractions, trading them for categories like 'dog' and 'car' which have very little practical use in typical programming.

<comment><USER9> >>No. The math notation that is used across all branches of mathematics is consistent and unambiguous (the notation of formal logic, naive set theory, etc). << Nonsense. Actually, ambiguity starts with basic arithmetic. Take multiplication for example. We have several kinds of notation for it. Which is inconsistent. In the case of juxtaposition, it's ambiguous because two or more juxtaposed letters don't necessarily imply multiplication. And I'm talking about arithmetic only. Then, ambiguity only builds up. Cross product, Dot product & crap.

>>>Being able to say 'group' instead of 'set with an associative binary operation with identities' is essential <<< OK, but the word "group" should be used for no other meaning...

>>>The reality is that you are not the target audience of their communication, and they are okay with that. You should be too.<<< As you can see pretty much anyone is the audience of some math and its inconsistency and ambiguity. It just varies the level and the amount of it.

>>>The weirdest assertion that you made is that high-level programming languages ought to be as close as possible to human languages. The two categories of languages exist to communicate fundamentally and widely different groups of concepts. Words represent categories of analogous concepts, and the relevant categories in human life are nothing like the relevant categories in programming. In Haskell, 'functor', 'applicative functor', and 'monad' are highly relevant categories. They pop up everywhere and can be leveraged with great benefit.<<<

False. Computers and software are mainly used to emulate some real world stuff (objects, actions etc.) and to help people with real world stuff in a more automated way. They aren't used too much to prove theorems or some other math stuff. And pretty much no one cares about proving the so called "mathematical correctness" of a program - a concept that doesn't even make sense in most cases. Old misconception among FP advocates, even Dijkstra himself admitted that he was kinda wrong about how computer would evolve and what they'd used for. But the associated misconceptions live on. A language close to human language also helps avoiding errors. That's why you won't see functional languages in critical systems, but rather languages like Ada which is probably the closest programming language to human language. The claims of clarity of FP languages are pretty much at odds with the evidence the real world provides.

<comment><USER10> You are simultaneously arguing that we should be using a natural language and that the language of mathematics is too ambiguous. I think you have not looked very closely at natural languages.

<comment><USER9> A programming language can be created such that it resembles a natural language but it also avoids the ambiguities of that natural language. Anyway, the main idea is that FP languages are way too cryptic and ambiguous, they use too many symbols with multiple meanings which don't make any logical sense at a first glance. If you have to go to great lengths to explain the meaning of a simple symbol, then its use is wrong in a language that is claimed to be general purpose, clear, easy to read and so on. Either that, or the language is not general purpose and/or doesn't have those claimed qualities (clear, etc.) in a general sense.

<comment><USER10> Or, you simply have not learned enough yet to understand the language. Programming languages are not designed to be easy to pick up with no prior knowledge, they're designed to be powerful when used by professionals who actually know what they are doing.

If you're going to make the claim that functional languages use ambiguous symbols, you're going to need to back that up with some examples. I find it exceedingly hard to believe that there is any ambiguity in the operators of a statically and strongly typed language like Haskell.

<comment><USER9> Or, maybe the language is very poorly designed. There are many programming languages. From Basic to LISP to C to Java to Haskell to ... Brainfuck. Some of them are used in the software industry and some are not. There are many claims about many languages: language x is good because [insert some random ramblings], language y is good because [...] However, no language is adopted by the industry solely based on claims (and btw. I have seen some utterly ridiculous claims made by those who try to promote Haskell.) Every once in a while, some companies try out new languages. Very few such languages get adopted and as you can see functional languages are almost completely absent from the industry. And there's a very good reason for it: they're simply not suitable for producing professional grade commercial software. If it had been otherwise, someone would have figured it out. The funny thing is that the start-ups that try to use them (usually founded by FP advocates themselves) also fail one after another. But some people never learn. Furthermore, many companies forbid the use of functional style or characteristics implemented in certain imperative languages. The code of good, proper lanaguages for general purpose software engineering, is almost self describing! What is unclear should be sorted out quite easily using the documentation.

Those "professionals who actually know what they are doing" don't seem to exist when it comes to functional languages. The evidence is the very fact there's not a single piece of important commercial software written in such a language. The question is rather: can such specialists exist? Because I'm afraid they can't exist because the functional approach is fundamentally wrong.

Examples of ambiguity in FP? What is the following line supposed to mean and what part of it suggest anything about that:

a b c

How is ~ an intuitive replacement for minus? How is (* 5 5) supposed to be as clear as 5 * 5 ?

ps. dynamic typing and type inference are two awfully bad things and either of them can lead to trouble in large programs

<comment><USER10> Honestly, I'm chalking this up to Poe's Law at this point. Take care.

<comment><USER9> LOL... that's all you had to reply? Typical of FP advocates..

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Haskell looks very interesting but I can't help but ask 'why do I need it?'. Currently I am learning Java since I want to get a jr.developer job later on and Ruby for some scripting and personal projects(maybe even Rails later). So Java is used in industry, Ruby is used in web and metasploit/ronin (something that I like to mess with), but what about Haskell? I am genuinely curious what Haskell can offer. I always see it mentioned on Reddit but I have yet to come across any notable project written with it. Could somebody with experience give me some reasons for me to learn it?

<comment><USER12> > I always see it mentioned on Reddit but I have yet to come across any > notable project written with it.

xmonad, one of the best tiling window managers for Linux, is written in Haskell (and is open source).

<comment><USER7> Not sure if it's notable, but I like hpodder, a command-line podcast client. It happens to be written by one of the author of RWH.

</comment></comment></comment><comment><USER13> Also useful:

Introduction to Haskell lecture slides - <http://shuklan.com/haskell/>

Real World Haskell - <http://book.realworldhaskell.org/>

</comment><comment><USER14> I think there's a dozen or so free haskell books:

[http://www.reddit.com/r/haskell/comments/1af3iw/9_best_free_...](http://www.reddit.com/r/haskell/comments/1af3iw/9_best_free_haskell_books/)

[http://www.linuxlinks.com/article/20130316105209238/BestFree...](http://www.linuxlinks.com/article/20130316105209238/BestFreeHaskellBooks.html)

</comment><comment><USER15> Anyone interested in functional programming might also be interested in LiveScript <http://livescript.net/>

</comment><comment><USER16> Good book. Previous discussion on HN:

<https://news.ycombinator.com/item?id=535675>

<https://news.ycombinator.com/item?id=336085>

</comment><comment><USER17> I'll reccomend Erik Meijer's videos on introductory Haskell. I haven't gotten though them all but I appreciate his style and depth of knowledge on the matter; he also points out many things that a Java or C# dev would naturally be curious about how to interpret Haskell.

[http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer- Func...](http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Functional- Programming-Fundamentals/Lecture-Series-Erik-Meijer-Functional-Programming- Fundamentals-Chapter-1)

</comment><comment><USER18> I didn't like LYaHfGG.

Take this in p52 for instance:

maximum' :: (Ord a) => [a] -> a

maximum' [] = error "Maximum of empty list!"

maximum' [x] = x

maximum' (x:xs) = max x (maximum xs)

Now, you may think that implies that you could do something like this to print a string one character at a time:

rsoat (x:xs) = show x (rsoat xs)

Buy you can't. If you try that Haskell complains "The function 'show' is applied to two arguments, but its type 'a0 -> String' has only one...."

Fair enough, one might reason - you're just passing max two things when it wants one so we can do something like this:

rsoat [] = []

rsoat [x] = show x

rsoat (x:xs) = rsoat xs

But no, that just gets you the tail of your string because x:xs doesn't match x so it never prints the other bits.

What you may end up doing is something like this:

rsoat [] = []

rsoat [x] = [x]

rsoat (x:xs) = show x ++ (rsoat xs)

But that's still not really doing what you wanted to do in the first place. It's sticking all your characters into a string and then reading that string all at once. And it's not a particularly obvious solution either if you don't know the language.

This may seem a silly example. But what happens when, as is frequently the case, someone wants to retrieve the nth element of a list? (list !! n) Haskell, as learnt through Learn You a Haskell, can easily be expected to drive someone up the wall who starts asking such questions - it's not a whole bunch of fun to play with.

<comment><USER19> To be honest, it does not seem you did a very good job of reading the book. If you're rooted in imperative languages, it takes some effort. I read the book when I had already had some basic functional programming experience, so my experience might not be so representative, but I've heard quite a few positive reviews from people for whom it was the first introduction to FP.

You seem to start off from a wrong premise that the show function prints things. It doesn't - it simply converts whatever value (of type a) you give it to a String (provided a is an instance of the Show typeclass). So seeing that you already have a string, a function which converts things to strings will probably not be very useful.

> rsoat [] = [] > rsoat [x] = show x > rsoat (x:xs) = rsoat xs

> But no, that just gets you the tail of your string because x:xs doesn't > match x so it never prints the other bits.

Uh, no. It doesn't give you the tail of the string, it gives you a list containing just the last element of the argument (if the argument's not empty), or the empty list (if the argument is empty) - which you can read directly from your definition.

Furthermore, " x:xs doesn't match x" doesn't make a whole lot of sense - it's not supposed to match x, it's supposed to match a non-empty list. Which it does, and the first element of such a list gets bound to the parameter x - <USER2> you do not use the parameter in your right-hand side of the definition, so you effectively discard it.

Note that both pattern matching and the Show typeclass (and the corresponding function) are discussed in the book prior to the minimum example.

<comment><USER18> > You seem to start off from a wrong premise that the show function prints > things.

No, I know what it does. That's how the book describes it however:

"The most commonly used function that operate on instances of this type class is show, __which prints the given value as a string__ "

> Uh, no. It doesn't give you the tail of the string, it gives you a list > containing just the last element of the argument (if the argument's not > empty), or the empty list (if the argument is empty) - which you can read > directly from your definition.

I continually forget that tail means the rest of the thing.

> Furthermore, " x:xs doesn't match x" doesn't make a whole lot of sense - > it's not supposed to match x, it's supposed to match a non-empty list. Which > it does, and the first element of such a list gets bound to the parameter x > - but you do not use the parameter in your right-hand side of the > definition, so you effectively discard it.

We're far enough away from what each other are thinking that this just isn't worth talking about as written.

You've already matched your list to x earlier in the program so x:xs doesn't get a chance to run. You're not showing x and then falling through to pass xs to the function again and chopping the first element off of that to show - <USER3> so on.

> Note that both pattern matching and the Show typeclass (and the > corresponding function) are discussed in the book prior to the minimum > example.

This:

<http://i.imgur.com/7NKReoL.jpg>

is _not_ a discussion of the show type class and corresponding function.

<comment><USER19> Fair enough, I don't have the printed version around. It's wrong on that point and I can see that it can be misleading. To their credit, here's the current formulation from the online version:

> Members of Show can be presented as strings. All types covered so far except > for functions are a part of Show. The most used function that deals with the > Show typeclass is show. It takes a value whose type is a member of Show and > presents it to us as a string.

This is correct. Whether it qualifies as a proper discussion might be debatable, but since the particular typeclass is simple enough, and seeing that this appears very early in the book, it seems reasonable.

> You've already matched your list to x earlier in the program so x:xs doesn't > get a chance to run. You're not showing x and then falling through to pass > xs to the function again and chopping the first element off of that to show > - and so on.

This is incorrect. Definitions are not really "executed" (or run) in Haskell; you simply replace the left-hand side of the definition with the right-hand side. You use the first definition (in file order) with a matching LHS. So in your example, the third definition for rsoat would be used for all lists with more than one element. So the "falling-through" as meant here is not what you get with, say, a switch statement in C.

</comment></comment></comment></comment><comment><USER20> I really liked LYAH, but it only starts out good. Once you hit Chapter 9. I/O. Prepare to fall off the rails. It only gets worse and worse and worse from that point onwards.

I don't think that's really the books fault as much as it is Haskells. I also think it's why you hear ALOT of people swearing Haskell is actually very easy, because everything up to chapter 9 is not very complicated at all.

I'm sure there are some very tallented people where this isn't true, but I get the impression that the people who are saying it's easy haven't gotten to the point where you can actually do things with Haskell, or developed a program with Haskell, or inter-operate with other libraries using Haskell, or tested their metal against the Parsing Combinators in Haskell (let alone making your own set), or ect. ect. ect.

Chapters 1-8 aren't complicated in the slightest.

Chapter 9 is when it starts.

Haskell isn't easy.

</comment><comment><USER21> Is the name of this book some sort of inside joke or something?

<comment><USER22> It is a joke, but not an inside joke as much as a joke that would be understood by people from Balkan countries (Serbia, Croatia, Bosnia). Miran (the author of LYAH) is, judging from his first and last name, from this region. In the local language (Serbian, Croatian and Bosnian are basically the dialects of the same common language), the most commonly used word for teach and learn is the same word, uciti, although there are separate words for these activities. Basically, whether you speak of teaching someone, or learning something is judged by the context. Then, Learn you a haskell vs. teach you haskell is a wordplay in that sense. A similar joke from the region: "Can you translate me to the other page of the street?"

<comment><USER23> Of course the strangest part of the title is the article "a" since "learn you" is a valid if unusual idiom in English.

</comment></comment></comment><comment><USER24> I'm fairly certain I've seen this posted to HN before... good book, though!</comment>


We need to change startup culture: Gender Edition - <AUTHOR> http://chrnguyen.com/writings/2012/9/30/we-need-to-change-tech-startup-culture

<comment><USER2> I've interviewed over 200 applicants... three or four were women and like all but a few of the 200 applicants they were dreadfully unqualified. I guess that is why we have a 100% male company now at 10 employees. I wish this were different, I really do. Give me a 50/50 gender company and I would be a happy man. Sadly from where I am sitting it does not even seem remotely possible.

I'm thinking we need to fix social stigmas against female engineers at a much lower level.</comment>


Show HN: Bad Mouth - Make anyone say anything - <AUTHOR> https://itunes.apple.com/us/app/bad-mouth!/id733442827?mt=8 Here's an example: http://www.badmouth.co/iEpjJOtMkV <comment><USER2> I'd like to share here my idea of image-processing app [http://www.windowsphone.com/en-us/store/app/bubbling- undress...](http://www.windowsphone.com/en-us/store/app/bubbling- undresser/53afdb61-8381-4ae4-8659-a9a4e788e4a4)

Sources available on github, if anyone is interested (: [https://github.com/x4m/NetWire/tree/master/SourceForgeExport...](https://github.com/x4m/NetWire/tree/master/SourceForgeExport/branches/bubbling)

</comment><comment><USER3> I went to the website hoping to see the app in action... but it just links back to the appstore. Would you please post a video demo? I think it would increase downloads.

<comment><USER4> Its a free app. Just try it...

<comment><USER5> People who don't have an iPhone might like to see how the app works.

</comment></comment></comment><comment><USER6> This is fantastic. So much fun and well executed. The hold and zoom feature for smaller erasers is perfect.

<comment><AUTHOR> Thanks!

<comment><USER7> Love it! thanks.

One thing though, for some reason during the tutorial I thought something was broken at the end.

Even though there was a massive tick symbol on the screen, I was pressing the 'arrows' button to try and progress.

I would suggest on that final screen changing it to a big clickable 'Ok!' or something.

<comment><AUTHOR> Thanks for the feedback. I need to show that the check mark is how you mark a video as done and progress. The intent could be clearer though, I'll look into it.

</comment></comment></comment></comment><comment><USER8> Haha, looks cool :) ... you gonna create an Android version? I wish I could try it.

<comment><AUTHOR> Sorry, just a side project for an iOS dev. Maybe if it got very popular.

</comment></comment><comment><USER4> It would be interesting to see how well (how much money you make) with the ads.

<comment><AUTHOR> It's still very new so I don't have enough users to make more than a negligible amount a day. If anyone has any leads or ideas for marketing, I'd really appreciate it.

<comment><USER9> Twitter to some celebrities with them saying funny things?

</comment></comment></comment><comment><USER10> Really fun! Great job, how many hours did you put into it?

<comment><AUTHOR> Thanks! About 4 months nights and weekends for the app and the website.

</comment></comment><comment><USER11> This is hilarious. Well done!

</comment><comment><USER12> Reminds me of classic Conan!

<comment><AUTHOR> Yeah! That's where I got the idea.</comment></comment>


An Elegy for the Landline in Literature - <AUTHOR> https://www.newyorker.com/books/page-turner/an-elegy-for-the-landline-in-literature <comment><USER2> I would say that a smartphone is not quite so reliable as this author seems to think. Batteries and signal fail all the time, for one. The drama that can be created with smartphones is at least as much as that created with a landline. Text messages, for example: what about a message half written and accidentally sent, or the sending of a risky text and seeing a long typing indicator before recieving just "OK", or perhaps an unsent message left to be rediscovered a day or so later, after everything has changed? Or with calls: the embarrassment of realising too late that you're on speaker, or calling a hundred times and hearing only "the number you are calling is not available" (why? Is it no signal, have they turned off their phone?), or even just getting a call from an unknown number, which has all the mystery of a call from a landline. Even caller ID has drama: why are _they_ calling at this hour? Is the person on the phone the same as the caller ID? Social media adds so much, too. Is it Facebook, where you're friends with your parents, or Snapchat, with just your friends? Is it a public post, or a select group? There's so much scope for drama, and we're seeing more and more use of it in modern writing.

</comment><comment><USER3> I read an article a few years ago about how authors have had to restructure stories because so many plots have hinged around people being out of touch except when at known locations. A lot of mystery/misunderstanding of plots (think: PG Wodehouse) no longer works.

I was struck by this article (within the last decade) as mobile phones and texting have been ubiquitous since the mid 90s (early 00s in the US). Funny that popular literature took a while to catch up.

Detective stories survive this the best (nothing is "real-time") and historical fiction (no phones in Ancient Rome).

Ironically this traces a thread of literature. "The Moonstone" by Wilkie Collins was the first mystery story and also the first technologically "modern" story as it was the first in which people could telegraph to London and have a detective arrive by train later in the day! Still a great novel even though Collins has gone from the height of fame (Far more more famous than his contemporary Dickens) to obscurity today. Like the telegraph and landline.

<comment><USER4> > I was struck by this article (within the last decade) as mobile phones and > texting have been ubiquitous since the mid 90s (early 00s in the US). Funny > that popular literature took a while to catch up.

I've mused about this a bit myself, it's and interesting topic. I've never reached a conclusion, but some of the factors I consider to be important:

* The future is already here – it's just not evenly distributed. (william gibson) There are many people my age (40) who didn't really have cell phones until the last 10-15 years. It's like cord-cutting: I haven't had cable in 20 years, neither have many of my tech friends, but a lot of folks seem to have only caught on en mass in the last few years. Similarly cell phone usage being ubiquitous in my techy peer group may not represent everyone, true ubiquity may be much newer.

* Related to the above, there's the tech phase in period. Once cell phones became ubiquitous, it's not like it instantly changed the habits and modes of thinking of those folks immediately. Between the limited number of talk minutes back in the old days, and the true ubiquity of landlines, cell phones were seen as an accessory, a secondary communication method. This still remains true institionally: you'll find lots of forms that ask about landline vs cell, or assume landline is the primary phone number, etc.

This also includes the notion of: we had to figure out how to use this tech. I don't mean it in the way of "how do i press the right buttons" but rather "what's the socially correct way to use this thing?" Is it OK to take a call in public? What's the expected response window for a txt? How does that prioritize with calls? What is polite on txt (which used to have a 140char limit per message that cost $.05 to send), and so on.

* There's some form of inertia involved. The telephone changed details, but not the fundamental idea that a person's reachability was tied to location. I mean, a telephone number went to a phone in a specific room (not strictly true, but close enough). Until the cell phone, this had been true forever, so millenia of story structure and concepts are built around it. Everyone was (and honestly still is) used to the idea and had built a lot of understanding around it. That understanding takes a little while to change, and if it's the only thing you've ever known, it may take a long while. Conversely, writers who grew up with mobile as the primary communication method and understand it as a core idea are only just now getting to the point where they are able to produce good stuff - there's still the learning/experience curve for writing.

I think that last point could be rewritten pithily as: write what you know.

* Finally, since story structure that has existed forever is broken by cell phones - it's possible that writers just needed to observe the world a bit to see how the conflicts changed as a result. Sometimes it can be fixed by patches "oh we can't do a search here, they have cell phones"... becomes "oh the battery is dead, do a search!". Other times the structure is just broken and must be abandoned. New structures can probably be invented, but that's hard.

Anyway, I don't know if the answers are in the above, but it's a fun topic.

<comment><USER5> It's a great point about habits. It probably took me a surprisingly long time before it became second nature to make a note on my phone (or more likely just take a picture) to remember something rather than make a note on a piece of paper. And I still sometimes find myself carrying around paper or plastic cards or copies of information that really aren't critical and could just as easily be a photo on my phone.

I suppose there's a downside to _everything_ being dependent on your phone but for non-critical stuff, it makes sense.

And it takes time to get comfortable. I gave up my landline fairly recently after deliberately avoiding using it at all for about 6 months--well, except once when Internet failed. But I finally decided that, while it can be somewhat higher quality and was something of a backup (though it was still from the cable co), it just wasn't worth $40/month as a backup.

ADDED:

>you'll find lots of forms that ask about landline vs cell, or assume landline is the primary phone number, etc.

This is one of my minor annoyances about giving up my landline. I really don't like giving out my cellphone number at random. For work stuff, I just give out my office number which doesn't even have a phone attached :-) But there is some personal stuff where I don't necessarily want to give out an entirely fake number but I don't want them calling my cell either.

</comment></comment></comment><comment><USER5> There are so many examples. In SF many of Connie Willis' stories revolved around constantly missed connections as someone ran around trying to find someone else. The film Play It Again Sam had a running gag in which one of the characters was constantly calling and giving a phone number about where he was at the moment. Anything written today that depends on a "missed connection" has to explain why someone couldn't just make a cell call (or otherwise do a search and reach someone).

<comment><USER6> I think I've seen it pointed out several times how absolutely bizarre the use of landlines and lack of cell phones is to young readers of _Neuromancer_ \- even leaving them wondering whether there is some deeper meaning behind that.

<comment><USER7> I remember _Max Headroom_ successfully predicting video telecommunications, but it resembled a 1980s telephone with a screen. There were even "View-Phone" booths on street corners. Also -- CRTs everywhere.

Some of this was probably deliberate; the show depicted computer consoles with ancient purely-mechanical typewriters. But still, I interpret the tagline "Twenty minutes into the future" as something of a _disclaimer_.

<comment> at-fates-hands I have a 1986 Playboy and in the "Tech Section" there is a image of a "video phone" which was basically a landline phone setup with a tiny 5" B&W screen with an image of the person you were talking to and it was hailed as the future of communications.

Behold, the Luma Telecom Video Telephone:

Looks like a press release from 1986: [https://www.upi.com/Archives/1986/04/22/Luma-Telecom-Inc- has...](https://www.upi.com/Archives/1986/04/22/Luma-Telecom-Inc-has-broken- through-the-high-cost-barrier/4751514530000/)

If you wanted some pics: [https://www.worthpoint.com/worthopedia/vintage- mitsubishi-lu...](https://www.worthpoint.com/worthopedia/vintage-mitsubishi- luma-video-phone-works)

[https://www.flickr.com/photos/fujipc/4578540563](https://www.flickr.com/photos/fujipc/4578540563)

<comment><USER8> Even weirder, things like this were still being marketed this century: [https://www.theregister.com/2004/09/15/amstrad_e3_launch/](https://www.theregister.com/2004/09/15/amstrad_e3_launch/)

<comment><USER6> Well, that was 3 years before the launch of the iPhone. It totally made sense at that time.

</comment></comment></comment></comment></comment></comment><comment><USER9> [https://archive.is/Cm90Y](https://archive.is/Cm90Y)</comment>


UK to bring in drone registration - <AUTHOR> http://www.bbc.co.uk/news/technology-40684581 <comment><USER2> I act as an advisor for DronesBench [http://www.dronesbench.com](http://www.dronesbench.com) and we think there should also be some sort of drone efficiency certification for the consumer market (from 250g to about 4kg, under 250g they are toys according to EASA legislation draft), same as other electro-mechanical devices or machines, with a concise parameter to be sported on the drone's plate. Too much a difference from the value declared by the vendor may imply hidden defects of the drone and therefore the possibility of a crash. We are actively proposing our DronesBench Index to IEEE and EASA for the legislation to come, with encouraging response from IEEE at the preliminary level. It remains to be seen if and how things progress in a formal way.

<comment><USER3> I'd love to see noise regulation. Nothing more irritating than being somewhere peaceful and beautiful when a couple of douchey drone flyers decide to ruin the quiet

<comment><USER4> I am all for reducing noise in our environment. But you hardly hear my copters if a car or motorcycle passes. Most AC makes more noise.

I don't understand this irrational phobia. Is the fact that it is flying triggering some deeper mechanisms in the brain?

It reminds me of my two year old's reaction to wasps.

<comment><USER3> Most AC isn't in secluded places of outstanding natural beauty, where drones increasingly are.

<comment><USER5> And many ACs break noise rules (often 40db in residential areas).

</comment></comment></comment></comment></comment><comment><USER6> OT: Is it just me who does not see huge business opportunies in drones?

Don't get me wrong. Drones made a huge leap the recent years and from a hardware manufacturer's POV there is business. There is also great stuff like drone races, drone cams and selfie cam drones.

But will there be really much more? Are safety concerns, public regulation and limited use cases in many areas (such as urban areas) giving drones a hard time?

<comment><USER7> Drone registration could actually boost the drone-business market.

Businesses should welcome registration because people won't just look at it and think "well I could do that myself!" because of the additional hurdle; hurdles that businesses will happily jump through. It'll separate drones more clearly into "toy" grade drones and business grade drones.

The businesses for drones are anywhere that you want equipment (particularly cameras but not necessarily) that previously it was too difficult or expensive to put a person for either due to practicality or safety reasons.

Drones are now reasonably cheap self-stabilising mobile platforms. They won't be going away, they'll just be incorporated into other businesses where appropriate. It's easy to laugh at drone-races and selfie-cams but as drones become more reliable, more efficient and quieter they'll just naturally find use cases.

<comment><USER8> That hurdle already exists in the UK in the form of Remotely Piloted Aircraft Systems (RPAS) certification (AKA Remote Pilot Competence), which requires passing a theory test, a practical test on the specific equipment that will be flown commercially, as well as development of an Operations Manual that is reviewed as part of the certification process. Commercial insurance is also required.

What the proposed registration process is attempting to address is the misuse of hobby multi-rotors.

The difficulty the it faces is in retrofitting it to an existing market. Those who are too dumb or ignorant to fly legally (and since multi-rotors have become too easy to acquire and fly, there are many), are going to be the ones who also fail to register.

Requiring registration prior to purchase is one possibility, and having mandatory geo-fencing on all new systems seems like the only way to gradually introduce a system that restricts use in controlled airspace, and over populated areas, but it will never be able to account for every scenario in which people insist on breaking the law, invading privacy or putting others at risk of injury.

</comment></comment></comment><comment><USER9> I generally don't have a problem the idea of registration, but 250g is way too low a limit. If 2.2kg is the FAA's lowest risk category, the limit should be closer to that.

<comment><USER10> It's not a limit. 250g is the _minimum_ weight at which drones are regulated. There would be little point in a new law which excludes drones under 2.2 kg as that is nearly all drones.

FAA is not a good example to cite either as their position on drones is a total mess and their existing regulations are a patchwork of legacy rules designed to cover model aircraft.

<comment><USER9> > It's not a limit. 250g is the minimum weight at which drones are regulated.

So 250g is the maximum limit for unregulated drones.

</comment></comment></comment><comment><USER11> >The plans also include the extension of geo-fencing, in which no-fly zones are programmed into drones using GPS co-ordinates, around areas such as prisons and airports.

So will open source drone firmware become illegal?

<comment><USER12> Not if it includes geofencing, obviously. There might be an opportunity to alter/delete the geofence, but that would not be different in a legal sense from "chipping" a moped for example. The chippability of mopeds does not make all mopeds illegal and selling properly geofenced drones with open source firmware would also be legal. Altering a drone to remove the geofencing and then flying it would be illegal though.

</comment></comment><comment><USER13> Currently mentoring a startup in this space (not in the UK). For us it's because of mandatory insurance for 3rd party liability, and as a non-drone owner who's seen plenty of idiots wielding them, I'm all for it.

I prefer the light touch (ala Mopeds/Scooters) where it's simple and easy, insurance at a flat rate, easy to transfer ownership. Something akin to cars with a v5 document, etc would be overkill.

I don't really have an opinion on the weight limits, how much does something have to weigh to take out an eye, or cause a motor vehicle to crash?

<comment><USER14> _how much does something have to weigh to take out an eye, or cause a motor vehicle to crash?_

I think things should be put in to context a bit. Seaguls where I live usually weigh more than 1-1.5Kg, and they are arguably more dangerous to be around if you happen to be a child holding an icecream!

<comment><USER13> Great point, in fact I've been bird struck whilst riding a motorcycle and that's DANGEROUS.

I dare say though that I trust the bird's self preservation instinct more than I trust flakey wifi and an FPV pilot somewhere a few hundred meters away.

</comment></comment></comment><comment><USER15> Portugal will introduce drone registration and insurance as well.

<comment><USER16> Yeah, I'm just waiting to see how that will be enforced.

<comment><USER4> Like everywhere else, it will be irrelevant in practice. But some lawyers made their career step.

If some people would adhere to speed limits like they praise "drone regulations", the world would actually be safer.

</comment></comment></comment><comment><USER17> Cant believe its taking this long... and only in the UK! these things can be retrofitted to be _dangerous!_

<comment><USER18> I can't tell if this comment is sarcastic or not. Could you expound on this a bit? What kind of retrofitting are you talking about, and how would registration help? The US also has drone registration as of a year or two ago, under the FAA. I'm not really sure what that accomplishes either, though. They might just be gradually ramping up to more aggressive restrictions.

<comment><USER19> The FAA registration was actually struck down (as of May 2017) for violating the FAA Modernization and Reform Act of 2012. The FAA is explicitly barred from regulating hobby model aircraft.

Interestingly, the FAA still promulgates the notion that you have to pay them $5 for the privilege of flying.

</comment></comment></comment><comment><USER20> Could you, I don't know, require a license on high power handheld lasers? I see imbeciles shining what looks like 100+ mW laser pens (very cheap, very easy to get) on people.

Now, I don't like laws banning stuff, but these handheld 150-2000 mW lasers can seriously damage someone's eyes. And I'm not going to risk _blindness or poor eyesight for the rest of my life_ because some idiot thought it looked cool.

What's a legitimate use for them? It seems to me that they exist only because "high power, fuck yeah". 50mW is enough for pointing at stuff, and you need industrial lasers to cut something.

Shining them in the sky and at people is already illegal, technically, but this is a real case where preventing purchase would be better.

<comment><USER21> And acid

<comment><USER22> What's a legitimate usage of acid? Plenty. Cooking. Engraving. Cleaning.

</comment></comment></comment><comment><USER23> License means More Tax.

Why am I not surprised?

\- Car License.

\- TV License.

\- Remember Personal Radios needed a License.

\- Gun License.

\- Travel License (passport).

Now Drone License. _sigh_

What else can the UK Government think of taxing?

<comment><USER24> I mean, most of those make sense - a 'car licence' (I assume you mean road tax?) pays for roads (in theory). A TV licence pays for the BBC. A radio licence presumably paid for the BBC before there were TVs. Passport fees pay for embassies and other foreign services.

It is hard to see how an expensive drone licence would be justified though.

<comment><USER25> TV licence is a big nuisance, and to me it's just old media clinging on to the power it holds. I go home and accidentally start streaming through the BBC iPlayer (I wanted to watch a catch up program but my finger slipped), am I breaking the law? Am I considered a criminal by the state?

If they want to enforce this properly they need to do it at the device level. If I'm not supposed to watch TV then make it impossible for me not to do so, put a login behind it or something.

Not to mention the ABSURD methods they go to intimidate you into paying, even when you don't watch live television (in my case, I don't even own an aerial cable), every month I get a threatening, amateur looking, in red writing, letter telling me about my crimes and that I will just end up in court.... If I kept these letters I'd have to rent a garage just to store them, have these people ever heard about saving trees? :)

It's a silly tax, with silly regulations and silly enforcement that needs to go.

<comment><USER26> We have a national TV network which is an absolute national treasure and produces some awesome TV. The TV license just ensures that the government doesn't hold the purse strings and therefore effectively controls it. I'm happy to pay for a TV license for this reason. Also, lots of channels with no adverts on is pretty good.

As for the letters, _just tell them you aren 't eligible to pay_. How do they know if you don't tell them?

For iPlayer, they are bringing in a BBC account which will be tied to your license fee, so you can't accidentally stream it.

<comment><USER27> National Treasure? It is literally state media, you only had to watch the BBC during the Scottish Indy Ref to show how far it will go to tow the government line. I think it is a disgrace so no longer have a licence. When Trump branded it FakeNews, people in the UK were outraged but it is one of the few things I agree with.

<comment><USER26> Is there any specific criticisms of the indy ref coverage you can give? None of the major broadcasters where particularly unbiased, because nobody wanted to see the union break up.

Trump brands a lot of things fake news. They rarely are.

</comment></comment></comment></comment></comment></comment><comment><USER28> While I laud the intent, I doubt bad actors will register their drones, so it'll be a burden for legitimate pilots and no deterrent whatsoever for folks who use them to fly contraband into prison etc.

<comment><USER7> Like many laws, it's not really supposed to act as a deterrent, it's just an easier way to administer the law.

If you find someone flying a drone dangerously, at the moment it's hard to know where to draw the line at what is legal, which then makes it difficult to prosecute someone who's flying drones recklessly (such as flying over airports).

If you have drone registration, then in the same scenario you can either take away their license (an action which doesn't require proof beyond reasonable doubt) or if they aren't licensed, you have a very easy law to prosecute against (flying without a license).

<comment><USER29> What about model airplanes? Do you need a license to fly a model airplane or helicopter?

<comment><USER28> Not currently, no, and it's not clear if this'll extend to those.</comment></comment></comment></comment>


Linus Torvalds Won't Say If He Invented Bitcoin - <AUTHOR> https://www.trustnodes.com/2019/10/02/linus-torvalds-wont-say-if-he-invented-bitcoin <comment><USER2> Anyone who believes these baseless vacuous claims about Linus inventing Bitcoin might as well grow a gigantic beanstalk out of magic beans in the ground.

<comment><USER3> If you plant your Bitcoin and fertilize with eth, a money tree will grow

</comment></comment><comment><USER4> I worked with a raving lunatic at a quantum startup in Toronto, where he (the founder) insisted fervently that he was the Bitcoin inventor. After the second time he brought it up, with me again forgetting to pretend I was impressed somehow, I totally gave up on him. His whole quantum product is probably a sham. Certainly the entirely fabricated life stories he continuously detailed to me, in addition to claims he had about what his product was able to do (I saw the code... from the parts I saw, it doesn't do what he tells his investors it does, and it was mostly copied from a Lisp meta-programming book readily available on the Internet for free) was a huge pipe dream stuffed with imaginative ego at the expense of reality. I only lasted a week because his nuttiness outweighed the income to be made working with him. Sad.

It seems Real Satoshis are a dime a dozen these days, 'cos they're popping up everywhere.

That is to say, until someone does something obvious to prove such claims, I have zero respect for anyone making said claims, and zero interest in articles claiming the probability of yet another OG Satoshi.

Linus probably just thinks it's too stupid to venture into that kind of discussion. And he'd be Wright.</comment>


Facebook's Open Compute Project - <AUTHOR> http://www.businessinsider.com/facebook-open-compute-project-history-2015-6?op=1

<comment><USER2> So is there anyone _not_ working for a multi-billion multinational that has any interest in OpenCompute?

I work for an integrator / VAR that offered OpenCompute hardware - one of the first thanks to some connections - but never managed to sell any. We gave up trying after about a year. The maintenance burden of keeping a product line alive that nobody wanted to purchase was too much for us to justify.

<comment><USER3> We're working on a project to use open compute racks and servers in a 20' shipping container on one end and a swamp cooler using evaporative media instead of a mister on the other end. It's similar to SGI's discontinued 16' ICE CUBE, but it will be a modular system (computer racks are only one type of module) and an it's an open design which will be donated to open compute (if they're open to the idea).

The idea is to be able to quickly and cheaply deploy infrastructure in developing SE Asian countries (we're in Phnom Penh).

The problem we keep running into is that when we contact venders selling open compute servers, they don't take us seriously because we aren't building out data centers with hundreds or thousands of racks....</comment></comment>


Diminished Reality - Remove items from a live video stream - <AUTHOR> http://www.popsci.com/technology/article/2010-10/video-voodoo-software-removes-objects-live-video

<comment><USER2> Offline adblocker! Alright!</comment>