Hacker News new | past | comments | ask | show | jobs | submit | zura's comments login

I'd put it on a par with SICP. A very enjoyable reading.


Any idea how Airport by Arthur Hailey is relevant today?

https://en.wikipedia.org/wiki/Airport_(novel)


Relevant in what way? It’s a work of fiction.


Just saw on the wiki:

"The book presents an overview of the operations of a major commercial airport, much of which is still applicable over 40 years later. Several major and minor characters appear, illustrating the vast complexity of the airport and its operations, including customs officers, lawyers, airport police, doctors, clerks, snow clearers, et al."

Seems like it's still relevant :)


The Knight in the Panther's Skin is a Georgian medieval epic poem, written in the 12th century by Shota Rustaveli:

https://en.wikipedia.org/wiki/The_Knight_in_the_Panther%27s_...


What about non-EU Europe, e.g. Georgia?


> Erlang (being replaced with C++)

Interesting. Any back-story about this? Also, what libraries do you use as processes (and OTP) alternative (if any)?


I'll provide the short version, and will encourage the exchange team to do a proper write-up once they feel ready for it. But to provide proper context, keep in mind that everything below is considered with a trading exchange in mind.

Distilled down to bullet point material, the change is driven by:

- language ecosystem; support libraries for Erlang are, regrettably, not that well maintained

- familiarity; the team maintaining and improving the exchange stack are not Erlang experts but know C++ pretty well

- hiring pool; finding good engineers who know Erlang is impressively hard. Intersection with engineers who have been exposed to financial exchanges is ... well.

- performance; as I've been explained to, the underlying data structures in Erlang are designed for maximum concurrency and share-nothing model (the Actor pattern in its pure form). These impose constraints that happen to hit the hot paths pretty hard. And related to that...

- memory model properties; exchanges rely on data structures whose critical paths cannot avoid invasive operations. Routinely working around your runtime's central assumptions is not exactly a best practice, regardless of the language used.

I will let our exchange team tell the complete back story, in their own style and with their view from the trenches. Known interest probably helps.


Thanks! It seems Erlang was not a best choice in the first place, for your project. Yes, please share the complete story when it's written.


curious too


A shameful plug from 2001, while we are at it :)

Playable: https://archive.org/details/tetris_201801

Tetris for DOS, text-mode but with colors! :)


You can actually use Perl 5 and even Python modules from Perl 6: https://github.com/niner


There are gotchas and unsupported functionality (e.g. 'since Perl 6 does not have the same concept of "context", Perl 5 methods are always called in list context.') which effectively mean that you've got no idea if library 'foo' will work or not without a thorough review of the code.

At best, it's a hack. Impressive, sure, but not something that you could rely upon. There's still no sane upgrade path here.


> At best, it's a hack. Impressive, sure, but not something that you could rely upon.

The same could be said for XS. And I do think that all of Perl 5 is relying upon that.

> There's still no sane upgrade path here.

FWIW, my blog post https://www.perl.com/article/an-open-letter-to-the-perl-comm... touches on that subject.


XS is the "same" hack all the time, though. A Perl library that can only be called in list context in Perl 6 is a substantial change from Perl 5. I've seen much smaller changes trash code bases before. I've got real code that would be affected by that. (I also think the context idea was a misfire in Perl <6, but as long as it is there, I've sometimes written code that had to deal with it.)

That said, why is it impossible to call a Perl 5 function in scalar context? Shouldn't the equivalent of Perl 5's "scalar" be fairly easy to implement? It may stink to have to manually use it, but it wouldn't be very often, and it's easy enough to use any of half-a-dozen Perl 6 features to minimize the syntactic hit.


> why is it impossible to call a Perl 5 function in scalar context?

Has Stefan (who wrote IP5) said or written that it's impossible?

18 months ago he wrote "So far I've found 3 different ways to implement scalar/list context for method/function calls".[1]

He has left issue #31 open.[2]

Where did you read that it's impossible?

[1] https://irclog.perlgeek.de/perl6/2016-08-03#i_12961486

[2] https://github.com/niner/Inline-Perl5/issues/31


"Where did you read that it's impossible?"

Grandparent of my post, no further research.

Bear in mind that as I posted doubt, that I am indeed doubting it, so don't expect me to be too surprised if you confirm that it is worth doubting. :)


> Microsoft has a cross-platform offering of some sort in the works using C++11

Casablanca, but I'm not sure how active is the project nowadays.


It's called the C++ REST SDK (https://github.com/Microsoft/cpprestsdk) now and is fairly active. I've used it client-side and I've really enjoyed it.


Why do you need to link statically?


Hey, I enjoyed your Perl 6 book this summer! Thank you! :)

Pity, there are no Perl 6 jobs so far...


> Hey, I enjoyed your Perl 6 book this summer!

That's great to hear. If you haven't done so, I'd appreciate it if you could write a review on amazon. There's a second one coming up: https://www.apress.com/us/book/9781484232279 / https://smile.amazon.com/dp/1484232275/

> Pity, there are no Perl 6 jobs so far

Not full Perl 6 jobs yet, but I heard from friends that they started developing some tools for $work in Perl 6.


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: