Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Would You Bet $100M on Your Pet Programming Language? (2007)

prog21.dadgum.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#71

Post by IndianAstronaut »

Ixiaus wrote: post #44

Caveat before reading my comment: this article is from 2007 and the scene 8 years later is pretty different but the spirit still holds, I think. The author also specifically placed "pet programming language" in the article's title which makes my reaction to it a bit unsound since, for example, Haskell is not a "pet programming language". WhatsApp built a 19B product on-top of Erlang. I'm building our startup's produc…

>I'm building our startup's product on a mix of Haskell and Erlang; so far it's going well.

Erlang is a very fascinating language. I am currently working on a small scale state and signaling system built in Java. After looking into Erlang, its way of dealing with similar problems is more elegant and much more scalable.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#72

Post by kedean »

Ixiaus wrote: post #44

Caveat before reading my comment: this article is from 2007 and the scene 8 years later is pretty different but the spirit still holds, I think. The author also specifically placed "pet programming language" in the article's title which makes my reaction to it a bit unsound since, for example, Haskell is not a "pet programming language". WhatsApp built a 19B product on-top of Erlang. I'm building our startup's produc…

I think you did kind of just prove his point though. 2007 was just about the time that Haskell started seeing its big boom in popularity and the unending series of 'how to monad' articles starting popping up, so when this was written Haskell wasn't really a proven language. In other words, WhatsApp kind of DID bet their $100,000,000 on their pet language, and came out ahead as a result.

My takeaway from the article wasn't that less popular languages are bad, it's that you should definitely consider everything before using them for a really important project. If your decision is that it will be a good solution, great! As long as you understand the limitations that you will run into.

These days I'd say that Rust is where Haskell was in 2007 (ignoring that Haskell came about in the late eighties). Its gone through a really long incubation period, and is about to get released into the wild, and is getting lots of press in the blogosphere. Now is the point where people will have to decide if its worth banking everything on writing a new, real project in Rust, because right now its still not much more than the pet language of some very vocal bloggers.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#73

Post by lmm »

gpfault wrote: post #49
lmm wrote: post #5

I was nodding along until I realized that the author has a very different notion of esoteric from mine. The last month of Fridays I've been tinkering with Idris, trying to get it to... well, do anything useful. I'd heard it was a dependently typed JVM language, which it is... kinda. Turns out you need to install a full Haskell toolchain to do anything with it. With the right esoteric option incantation, you can make…

By that logic, you should probably stop programming altogether because all runtime of managed languages is written in C. What if it all comes crashing down?!

I do worry about it. I probably wouldn't gamble $100,000,000 on any program, if I had that money to start with, because I could never be 100% confident in a system being bug-free. But I can minimize the surface area of C that I expose, and use better tools where possible (which is often). Given that I still do need to write programs (even C is more reliable than doing things by hand), what other option is there?

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#74

Post by MetaCosm »

kedean wrote: post #72
Ixiaus wrote: post #44

Caveat before reading my comment: this article is from 2007 and the scene 8 years later is pretty different but the spirit still holds, I think. The author also specifically placed "pet programming language" in the article's title which makes my reaction to it a bit unsound since, for example, Haskell is not a "pet programming language". WhatsApp built a 19B product on-top of Erlang. I'm building our startup's produc…

I think you did kind of just prove his point though. 2007 was just about the time that Haskell started seeing its big boom in popularity and the unending series of 'how to monad' articles starting popping up, so when this was written Haskell wasn't really a proven language. In other words, WhatsApp kind of DID bet their $100,000,000 on their pet language, and came out ahead as a result. My takeaway from the article w…

It is very annoying to me to hear Erlang referenced as a "pet language". It has been around as a language for 28 years, and it has been doing mission critical, soft realtime work of routing billions of phone calls a day for over 20. It wasn't some academic language with no industry chops.

Using it to dependably route billions of messages a day is not some crazy off the wall "adopting a pet language" -- it was picking a language that had already been proven (and explicitly designed) to work in a very similar problem domain. It was a smart, reasonable, sane choice that they then pushed to awesome extremes.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#75

Post by idlewan »

zzzcpan wrote: post #4

Here's one idea: why don't we compile every new language into a pretty C code? This way we will be able to use every available C library with a compiler of our choice and any extra C code, necessary for our real world application.

That's exactly what Nim does, and it works quite well.

The bindings are easy to create (there is an automated tool that does most of the work), they look like Nim function declaration and can add better typing checks on FFI calls. You still have manual memory management and pausable, optional GC.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#76

Post by [deleted] »

sheetjs wrote: post #50
Ixiaus wrote: post #44

Caveat before reading my comment: this article is from 2007 and the scene 8 years later is pretty different but the spirit still holds, I think. The author also specifically placed "pet programming language" in the article's title which makes my reaction to it a bit unsound since, for example, Haskell is not a "pet programming language". WhatsApp built a 19B product on-top of Erlang. I'm building our startup's produc…

It's funny you mention WhatsApp and Erlang, because the article actually addresses that point: > You're more dependent on the decisions made by the language implementers than you think ... some odd case that didn't matter at all for the problem domain the language was created for The language implementers (employee of Ericsson) made design decisions based on telecom constraints, exactly the same constraints faced by…

[deleted]

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#77

Post by MetaCosm »

sheetjs wrote: post #50
Ixiaus wrote: post #44

Caveat before reading my comment: this article is from 2007 and the scene 8 years later is pretty different but the spirit still holds, I think. The author also specifically placed "pet programming language" in the article's title which makes my reaction to it a bit unsound since, for example, Haskell is not a "pet programming language". WhatsApp built a 19B product on-top of Erlang. I'm building our startup's produc…

It's funny you mention WhatsApp and Erlang, because the article actually addresses that point: > You're more dependent on the decisions made by the language implementers than you think ... some odd case that didn't matter at all for the problem domain the language was created for The language implementers (employee of Ericsson) made design decisions based on telecom constraints, exactly the same constraints faced by…

Exactly, it is silly to consider Erlang a "pet language", it is an industry hardened language designed for the a near cousin to problem domain of WhatsApp. 20+ years routing billions of calls a day under soft real-time, high reliability requirements... because you simply expect your phone to work, even phone calls from one end of the world to the other.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#78

Post by lmm »

dietrichepp wrote: post #48
lmm wrote: post #31

Earlier quoted context omitted.

At the point where you're using a theorem prover you're not really writing C any more (I mean, do you count ATS as writing C?). It's a perfectly good way to produce reliable code, sure. But I'm pretty sure it's not what the article is advocating. > And then, as ill as you speak of C, you turn around and plug your Java systems into C systems, such as Varnish, Nginx, Apache, PostgreSQL, or thousands others that you use…

I'm just taking two lines from the article: "Reliability and proven tools are even more important than libraries"... in this case, there are a lot of proven tools for writing C programs, including the theorem provers. And "You're more dependent on the decisions made by the language implementers than you think"... there have been a lot of flaws in the JRE over time, most of them from the parts of the JRE that are writ…

The January 2013 flaws affected end users running the browser plugin, not systems written in Java. I suppose if you had a system that allowed users to submit their own bytecode and used Java's native facilities for handling this, then you'd be vulnerable. But nothing forces you to do that; someone who's capable of writing a safe bytecode verifier in C is certainly capable of writing one in Java.

The only even vaguely recent flaw I can remember in the JRE was, as you say, in the part written in C (I think in some image loading code). It takes a very perverse kind of logic to say: this system which is mostly not-C and a tiny bit C keeps having security flaws in the C part, therefore we should switch to systems which are written more in C. If the tooling for verifying C is really so good, why not verify the C parts of the JRE? Then they'd be proven once and for all, and lots of systems would benefit.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#79

Post by NateDad »

kibwen wrote: post #59
desdiv wrote: post #34

Earlier quoted context omitted.

None of the primitive data structures will match up. JVM languages, CLR languages, Rust, Go, et al all have array bound checking, so their arrays won't be compatible with C libraries without a wrapper.

Rust arrays are perfectly compatible with C arrays, they're both just contiguous segments of memory with elements at fixed offsets. You can pass Rust arrays to C functions trivially, and bounds checking has nothing to do with it. I should also note that all correct C code does bounds checking somewhere . The difference with languages that are bounds-checked by default is that they pessimistically assume that you have…

Ditto for go arrays.

Re: Would You Bet $100M on Your Pet Programming Language? (2007)

#80

Post by lmm »

zzzcpan wrote: post #53
lmm wrote: post #22

Earlier quoted context omitted.

If you absolutely need a C library, almost all languages give you a way to do that. But why hobble your compilation strategy for all programs just to support this occasional use case better? You may well want to target a runtime (JVM, .net, Javascript) for which no good C compiler exists. Even if you're solely interested in building native executables, compiling to C would mean throwing away a lot of information (e.g…

I don't think it is so rare, that you could call it occasional. That's the author's point and mine as well. Sometimes I need sqlite, other times libjpeg, giflib, libpng and some simple image processing with at least some low-level code. And it takes a lot of effort to make these things work with other languages on different platforms. Golang tried to make it easier and it still isn't. Optimizers is also one thing I w…

> Golang tried to make it easier and it still isn't.

How much of that is because Golang doesn't compile to C, and how much is because the languages just don't fit? E.g. you'd still need a way to mark whether Golang was supposed to garbage-collect a value that had been returned from a C call, or not.

> Most of the systems already have C compiler installed, if you target it, there is no friction in setting up building environment and so on.

Yes there is, because you still need to build the thing that interprets to C. If anything there's more friction than having a compiler that directly builds native binaries like e.g. ghc, because you need two tools - your translate-to-C tool and your C compiler. "Most systems already have a C compiler" is only really true on *nix; it will be easier for a Mac or Windows user to run your system if you distribute e.g. java bytecode.

Post reply on HN