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

Hack: a new programming language for HHVM

code.facebook.com

Post reply on HN
Print view View original

231–240 of 422 posts

Re: Hack: a new programming language for HHVM

#231

Post by Touche »

bos wrote: post #110
Touche wrote: post #90

This rubs me the wrong way. > Thus, Hack was born. We believe that it offers the best of both dynamically typed and statically typed languages, and that it will be valuable to projects of all sizes. In which way does it offer the benefits of dynamic typing? The entire point seems to be to abandon dynamic typing, which is fine, but not what that sentence says. I'm guessing, for example, you can't really do meta-progra…

It's more accurate to say that the point is to let you use dynamic typing where that makes sense, and static typing in the many cases where it helps. Hence "best of both".

This comment seems to indicate that you can't use dynamic typing: https://news.ycombinator.com/item?id=7437907

Re: Hack: a new programming language for HHVM

#232

Post by nbm »

cpeterso wrote: post #204

Is Facebook's code so monolithic that they can't deploy new, decoupled services written in new languages? Twitter did this with Ruby, Java, and Scala. Didn't Facebook create Thrift RFC for exactly this purpose??

Facebook already has several decoupled services written in other languages. The PHP codebase is mostly the front-end code which, beyond some database work, dispatches heavy lifting to back-end services written in C++, Java, and other languages.

As you say, Thrift connects this all. You can look into our C++ core library, Folly, and other C++, C, Python, and Java applications and libraries like Rocksdb, Presto, watchman, Buck, flint, scribe, and so forth on github.

Re: Hack: a new programming language for HHVM

#233

Post by munificent »

bluetech wrote: post #208
munificent wrote: post #205

Earlier quoted context omitted.

> Only way around the type system is void, explicit casts and I guess unions. And typedefs. Given that there's no parametric types, you run into void* quite frequently as well, so saying "only" inaccurately minimizes the scale of how much C code isn't strictly type safe.

Right, void* is used quite a lot for "generic" data structures. But I'm not sure that's what he meant. The reason I said "only" was that from my own experience, most C data structures are tailored for a specific use and so I don't see void* too much in this context. And may I ask why you say "typedef" is unsafe? It is merely a type alias, like e.g. Haskell's and ML's "type", or isn't it?

> It is merely a type alias, like e.g. Haskell's and ML's "type", or isn't it?

It is, but it freely allows conversion between the aliased types.

    typedef int Feet;
    typedef int Meters;

    int main() {
      Feet height = 6;
      Meters inEngland = height; //

Re: Hack: a new programming language for HHVM

#234

Post by dasil003 »

nostrademons wrote: post #206
Silhouette wrote: post #191

Earlier quoted context omitted.

I didn't have some some specific, technical definition in mind, but if I were to try and pin it down, perhaps in software terms it would be something like "a dependency that is unreliable in the long term". Clearly this isn't an absolute scale. As our industry evolves and we develop more reliable ways to achieve our goals, something that we regarded as being a relatively stable foundation in the past may no longer be…

If you define "crumbling foundations" as "a dependency that is unreliable in the long term", then your conclusion is circular. Of course no long-term products will be built on crumbling foundations, because if a technology stack has long-term successes then, by your definition, it is not a crumbling foundation. I think the other posters are using a definition of "crumbling foundation" as "one which most engineers hat…

I think it's funny that this whole thread is based on the initial haphazard word choice of reikonomusha yet he is not even a participant in the debate.

Re: Hack: a new programming language for HHVM

#235

Post by jfischoff »

bos wrote: post #133
copergi wrote: post #117

Earlier quoted context omitted.

>The fast development cycle -- edit php script, refresh -- is something amazing that you don't get in a lot of statically typed languages You seriously think that? That's how we do haskell web development. Both yesod and snap do this out of the box. That's how every java developer I know works.

I have a little bit by way of Haskell chops, and I'll venture that the performance of the Hack typechecker is a very big deal, and it is in a different breed than the turnaround time you get from snap or yesod (or Java).

what makes it a different breed?

Edit: I misread what you wrote. I thought you were saying there was something fundamentally different about the type checker, but more that reload experience is different then what you get with Yesod.

Re: Hack: a new programming language for HHVM

#236

Post by anaphor »

munificent wrote: post #233
bluetech wrote: post #208

Earlier quoted context omitted.

Right, void* is used quite a lot for "generic" data structures. But I'm not sure that's what he meant. The reason I said "only" was that from my own experience, most C data structures are tailored for a specific use and so I don't see void* too much in this context. And may I ask why you say "typedef" is unsafe? It is merely a type alias, like e.g. Haskell's and ML's "type", or isn't it?

> It is merely a type alias, like e.g. Haskell's and ML's "type", or isn't it? It is, but it freely allows conversion between the aliased types. typedef int Feet; typedef int Meters; int main() { Feet height = 6; Meters inEngland = height; //

I'm pretty sure you and the parent were thinking of Haskell's `newtype` not `type`

λ> :{

Prelude| type Feet = Int

Prelude| type Metres = Int

Prelude| :}

λ> let a = 5 :: Feet

λ> let b = 4 :: Metres

λ> :t a

a :: Feet

λ> :t b

b :: Metres

λ> a + b

9

λ> let f = id :: Feet -> Feet

λ> f b

4

Re: Hack: a new programming language for HHVM

#237

Post by teacup50 »

gfodor wrote: post #225
teacup50 wrote: post #219

Earlier quoted context omitted.

> Congratulations for admitting your ignorance, and lending open ears to experts as to why they made certain engineering decisions. Yes, they made certain engineering decisions now because the decisions they made back then were stupid, and they have to dig themselves out.

Yes and the OP is criticizing the decisions being made now as "yak shaving." Could it perhaps be that the "yak shavers" made a conscious and well-reasoned decision to go in the direction of "extend PHP" vs "throw it all out and rewrite everything in language-of-the-month?"

I'm sure it was conscious and well-reasoned, but the OP's point still stands.

Trying to build a reasonable forward-looking high-performance managed language runtime platform is hard.

Trying to build it atop of PHP is harder.

The only way I could see this as being a smart long-term strategy is if the eventual goal is to isolate and retire PHP projects entirely (and PHP usage itself) over time.

However, even then, with PHP gone, and Hack no longer necessary, you're still stuck maintaining your own incompatible VM / runtime. Is Facebook signing up to reproduce the CLR? Or do they have long term plans to somehow bridge the gap between HHVM and more established VMs/runtimes, where they can better share the maintenance load with the wider industry.

Re: Hack: a new programming language for HHVM

#238

Post by ghotli »

lectrick wrote: post #230
lbrandy wrote: post #85

Earlier quoted context omitted.

> I am baffled as to why you'd build your castle atop a crumbling foundation. Because perfect is not the enemy of the good? Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? Unless you have some example of perfect, now dominant, technologies that have been created ex nihilo that I'm missing? I mean we (facebook) are…

Given a programming task, it will be written faster, easier, and in a more maintainable and less bug-prone fashion if it is not PHP. The opposite opinion is basically indefensible. Sure, you can still dig a trench with a spoon (and if you have enough money to wield a bunch of workers with a spoon), even if a shovel would do a better job. Let's begin. 1) PHP autocraptastically converts strings that look like numbers,…

I can't fathom why you're under the impression that some code hasn't been switched to another language. Furthermore, your vitriol seems quite effective at undermining your thesis.

Re: Hack: a new programming language for HHVM

#239

Post by strlen »

eevee wrote: post #134
jwatzman wrote: post #65

Earlier quoted context omitted.

Engineer working on Hack here. Yeah, I think Hack is a good language to start a new project in. For as much flak as PHP gets, there are actually a lot of good things about the language. The fast development cycle -- edit php script, refresh -- is something amazing that you don't get in a lot of statically typed languages, which usually have a compilation step. The crazy dynamic things you can do also occasionally hav…

Er, `paste serve --reload` restarts small-to-medium Python projects faster than I can alt-tab, which is actually faster than my static blog engine can regenerate itself too.

Is there a statically typed variant of Python that would work with existing web servers, etc..? I am aware that there's Cython and I know that py3k technically permits type annotations (which Jetbrain's Python IDE uses quite effectively), but that isn't true static type checking in the same way as Hack does this.

Re: Hack: a new programming language for HHVM

#240

Post by orblivion »

lectrick wrote: post #230
lbrandy wrote: post #85

Earlier quoted context omitted.

> I am baffled as to why you'd build your castle atop a crumbling foundation. Because perfect is not the enemy of the good? Because "build atop a crumbling foundation" has demonstrated time and again to be, by far, the most successful way to accomplish anything in computing? Unless you have some example of perfect, now dominant, technologies that have been created ex nihilo that I'm missing? I mean we (facebook) are…

Given a programming task, it will be written faster, easier, and in a more maintainable and less bug-prone fashion if it is not PHP. The opposite opinion is basically indefensible. Sure, you can still dig a trench with a spoon (and if you have enough money to wield a bunch of workers with a spoon), even if a shovel would do a better job. Let's begin. 1) PHP autocraptastically converts strings that look like numbers,…

You're making a mistake. The question is not whether to start a company with PHP vs language X. The company is long started. The question is not whether or not to poof into existence a port from all of FB to language X. That's not possible. The question is, given that PHP is the current language, with all its faults, will it it cost more (including all definitions of cost) to make the switch? How long will it take? Does it get the job done? How bad is the damage?

The question more pertinent to your argument is, did they make a mistake years ago choosing PHP? That's when the could have conceivably gone with language X.

BTW the types of stuff you're listing are documented here. So thorough it's amusing to read: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...

Post reply on HN