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

301–310 of 422 posts

Re: Hack: a new programming language for HHVM

#301

Post by eevee »

orblivion wrote: post #240
lectrick wrote: post #230

Earlier quoted context omitted.

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? D…

Why thank you :)

Re: Hack: a new programming language for HHVM

#302

Post by bluesnowmonkey »

teacup50 wrote: post #250
dirtyaura wrote: post #241

Earlier quoted context omitted.

What was the stupid decision "made back then"? That Zuck wrote the first version of thefacebook.com in PHP, the language he was the most productive at? That the initial team didn't rewrite Facebook in Python/Perl/Ruby/Haskell during the fast growth phase? If you have ever experienced the growth phase, you understand how ludicrous the idea of rewrite would be. I've personally experienced and heard only horror stories…

> What was the stupid decision "made back then"? Using PHP to begin with was a bad technical decision. Failing to establish a reasonable migration strategy was a bad business decision likely rooted in bad engineering management that fell out of starting with bad technical decisions . It's much harder to hire people that can pull you out of a mess like PHP when, at the same time, you have to hire people that can keep…

> Using PHP to begin with was a bad technical decision. Failing to establish a reasonable migration strategy was a bad business decision likely rooted in bad engineering management that fell out of starting with bad technical decisions.

Facebook is a ten year old company with a market capitalization of $170 billion, so "bad" is probably not the most accurate word to describe their technical and business decisions.

Re: Hack: a new programming language for HHVM

#304

Post by mdance86 »

amenghra wrote: post #70
diegoperini wrote: post #43

Earlier quoted context omitted.

Perhaps Sublime Text 2?

We currently don't have Sublime Text 2 support, but it shouldn't be too hard to do, given Sublime's excellent plug-in design. Feel free to send us a pull request: https://github.com/facebook/hhvm/tree/master/hphp/hack/edito...

How about an MVC type framework, like Laravel for Hack?

Re: Hack: a new programming language for HHVM

#305

Post by eevee »

strlen wrote: post #300
eevee wrote: post #276

Earlier quoted context omitted.

Statically-typed Python would ruin a great number of Python libraries you'd probably want to be using. It'd be a very different language. Once you have type annotations, it wouldn't be too much of a stretch to enforce them statically with a separate tool. You could even go as far as rejecting first-party code if you can't statically determine every single value's type. Pylint's underlying astroid library has a bunch…

Such a tool would be no less difficult to build than hack itself, though. Hack's "gradual typing" solves the problem of re-using existing code that you've mentioned. FB already had a PyLint-like tool earlier that could do some static analysis, namely pfff (also open source and written in OCaml), but it did not provide a full-on static type system like Hack. (Background: I used pfff when I was in bootcamp at FB itself…

The announcement post says the actual type-checking happens in a persistent server that watches for filesystem changes. That sounds pretty close to continuously running a linter. It also says "without breaking things", so I'm a little fuzzy on whether badly-typed code will actually execute or not.

For that matter, can you call a typed function from an untyped one? Or, worse, a typed method? If the typing is purely static, there's no way to know the method you're calling is actually typed, so there's no actual guarantee that it receives the types it's declared unless your entire program is typed. It doesn't seem like a very strong guarantee if both the caller and the callee have to opt into the typing.

If you're looking for a tool that exists right now, you either have an existing codebase and can't port it to Hack if it's not already PHP anyway (for the same reason Facebook couldn't port away from PHP), or you're starting from nothing and could just use a statically-typed language in the first place.

I don't know if I'd even be excited about the prospect of optional static typing in Python. (It hasn't gotten me interested in Dart, for example.) I'd kinda rather see the effort poured into something that could do static duck-typed analysis/inference, e.g. balk if I pass an argument that could be a non-string into a function that tries to call `.startswith` on it. (Ah, but maybe it could theoretically be a string or None, and I only know it isn't None for reasons the type system can't see, and now I hate the type system.)

I didn't say it was a trivial problem. I just don't feel excited by the solution.

Re: Hack: a new programming language for HHVM

#306

Post by jaequery »

Silhouette wrote: post #279
nostrademons wrote: post #206

Earlier quoted context omitted.

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…

If you define "crumbling foundations" as "a dependency that is unreliable in the long term", then your conclusion is circular. Not at all. I'm arguing that in computing, worthwhile results often take time to achieve, and therefore that foundations that are likely to be around for longer will improve the chances of achieving such results. Alternatively, from the opposite point of view, the odds of achieving something…

hm interestingly, PHP still powers about 70% of the web! the web should have certainly crumbled by now ...

Re: Hack: a new programming language for HHVM

#307

Post by kamaal »

copergi wrote: post #272
munificent wrote: post #202

Earlier quoted context omitted.

> What major accomplishments in computing that have been built atop crumbling foundations can claim anything even close to the scale of success of these examples? Wikipedia and Facebook?

Neither of those would even remotely qualify is accomplishments in computing. But they also are terrible examples. Facebook isn't using PHP anymore, that's what this discussion is all about. Wikimedia is terrible, and wikipedia is almost exclusively static content being served by squid.

What are we discussing? Are we discussing about the tool or the things made from tools?

Its like trolling a raw cast iron hammer used to build a furniture factory and then saying the whole factory is entirely useless just because some invented a stainless steel hammer.

Re: Hack: a new programming language for HHVM

#308

Post by joesmo »

reikonomusha wrote: post #48

I am baffled as to why you'd build your castle atop a crumbling foundation. I have wondered why FB didn't use a proper language with proper typing to begin with. I mean, I "understand" logistically: they already had a giant codebase in PHP, migrating a codebase is expensive, and it's difficult to hire and train 1000s of hackers in e.g., OCaml. (They do have some OCaml people, but they are outliers. OCaml was my favor…

"And in the end, it's still PHP, which is duly disliked."

You might dislike it, but that doesn't mean it's disliked. PHP has a giant base of programmers, scales, is easy to learn, is extremely versatile and powerful, and as you point out, the code was already in PHP. Only an idiot would rewrite a giant working codebase simply to have it in a language that's "difficult to hire and train" in. Or any language for that matter. Perhaps they could have pulled a netscape but instead decided to serve billions.

Re: Hack: a new programming language for HHVM

#309

Post by AaronFriel »

DeGuerre wrote: post #287
discreteevent wrote: post #181

Earlier quoted context omitted.

"Windows has been a never ending refinement on exceptionally shaky ground." No. Windows NT was a complete rewrite and it was " well-conceived and theoretically well- founded"

What you say is technically correct, which is the best kind of correct. However, fewer than 1% of Windows programmers ever talk to NTOSKRNL, and probably an order of magnitude fewer do it regularly. Most of the time, you're talking to Win32/64 or high-level services based on DCOM or .NET, where the "well-conceived" and "theoretically well-founded" stuff doesn't turn up. You can go your whole career without knowing th…

For more than half of Windows developers, if you told them there was an object manager, they would ask how you can turn off that service to improve performance.

Re: Hack: a new programming language for HHVM

#310

Post by teacup50 »

sanxiyn wrote: post #293
teacup50 wrote: post #237

Earlier quoted context omitted.

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, wi…

Maintaining your own VM is no big deal. Compared to Facebook, HHVM is a tiny codebase. A team made of relatively small number of people (high quality, but low quantity) can and do maintain VMs like HotSpot and V8. LuaJIT is maintained by a single person.

> Maintaining your own VM is no big deal.

As someone who has worked on a VM, I couldn't disagree more. It can take years to hash out things as simple as ideally performing primitives for a target architecture, and then things change.

Add to that the complexity of optimizing compilers, specification of byte code formats and a consistent virtual machine memory model that can be relied upon across architectures, and the art and science of highly concurrent garbage collectors, and your "no big deal" is a load of hogwash.

Hotspot alone is nearly 20 years of big deal.

> A team made of relatively small number of people (high quality, but low quantity) can and do maintain VMs ...

The number of people doesn't matter in this equation; your small team of (expensive, rare, high quality people) can't build a world-class VM in a day. Or a month. Or a year. Maybe in 5 or 10 years, just ask Microsoft.

> ... like HotSpot and V8. LuaJIT is maintained by a single person.

LuaJIT's said "single person" has been working on it for what, 10 years? It's an extremely impressive implementation and I don't want to bag on it, but even still, it lags in certain areas, eg, its GC implementation isn't up to par with the state of the art.

The author's skillset is extremely rare, and LuaJIT itself is an anomaly in the field. Using such a one-off example doesn't really hold water to prove that it's ideal for a company to internalize maintaining a VM for their own custom language built on top of PHP.

Post reply on HN