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

Interview with Zig language creator Andrew Kelley [video]

youtube.com

Post reply on HN
Print view View original

51–60 of 210 posts

Re: Interview with Zig language creator Andrew Kelley [video]

#51

Post by logicchains »

petr_tik wrote: post #24
logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

how often does it happen that your interns work on the hot path of your trading systems, which is where I assume you care the most about avoid syscalls like malloc?

Literal interns are not very likely to work on it, but juniors might, and the junior's probably not going to know much more than an intern.

Re: Interview with Zig language creator Andrew Kelley [video]

#52

Post by littlestymaar »

logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

[deleted]

Re: Interview with Zig language creator Andrew Kelley [video]

#53

Post by dcolkitt »

petr_tik wrote: post #24
logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

how often does it happen that your interns work on the hot path of your trading systems, which is where I assume you care the most about avoid syscalls like malloc?

To be honest, I'd be a lot more worried about physics PhDs then I would interns. I've seen plenty of 20 year-old engineering students write solid low-latency code. I can't say the same thing about string theorists.

It'd be pretty unusual for junior or non-technical people to write code in "core" components of the system. Things like datafeed parsers, order handlers, inventory management, safety checks, networking libraries, exchange connections, etc.

But even with all these layers in place, you still need an actual strategy to run at the end of the day. Everything in the quoter can be optimized to hell, but if the strategy module is spinning for 1000+ microseconds because it's running some bloated ML model, then none of that really matters.

Usually the system engineers and the strategists are different people. Not always. Especially in the case of more straight-forward mechanical strategies. But anything reasonably complex usually requires dedicated quants with different skillsets than profiling C code.

Re: Interview with Zig language creator Andrew Kelley [video]

#54

Post by flohofwoe »

cmrdporcupine wrote: post #45
flohofwoe wrote: post #37

Earlier quoted context omitted.

Why not both? Zig and C are both very simple languages, and there's not much to "master" TBH (at least not many language-specific things, so what you learn mostly transfers to other programming languages as well).

To 'master' C is actually realizing C itself is not as simple as it looks from its syntax. It's an old language and the implementations are by no means straightforward. I'm by no means a C master but I have worked with people who are, and they know nuances of the language and the way it compiles down to various platforms in ways that shame me. But in general I have gone for for generalist not specialist in my career.

Well yes, but in the end all languages have this sort of fractal nature.

But there is diminishing value in how deep you want to go into the rabbit hole. Of course there's always more to learn, but with C you're fairly quickly leaving the language and move into the layers of compiler- and hardware-trivia (good to know nonetheless, but often not really relevant for being productive in C) where in other higher-level languages you're still working your way through the standard library ;)

Re: Interview with Zig language creator Andrew Kelley [video]

#55

Post by vmchale »

logicchains wrote: post #10

I work in HFT, and one of the key concerns when writing low-latency code is "is this code allocating memory, and if so, how can I stop it?" Zig is the perfect language for this use case as none of the standard library implicitly allocates, rather for anything that allocates, the caller must pass in an allocator. The stdlib also provides a handy arena allocator, which is often the best choice. This is a huge advantage…

Linear types would be even better though. Still safe like Rust.

Re: Interview with Zig language creator Andrew Kelley [video]

#56

Post by littlestymaar »

pron wrote: post #26
AsyncAwait wrote: post #21

Earlier quoted context omitted.

> This is a huge advantage over C++ and Rust, because it makes it much harder for e.g. the intern to write code that repeatedly creates a vector or dynamically allocated string in a loop. Or to use something like std::unordered_map or std::deque that allocates wantonly. True. On the other hand, Zig makes a deliberate decision not to bother itself with memory safety too much, so its a win some, loose some sort of situ…

> On the other hand, Zig makes a deliberate decision not to bother itself with memory safety too much This is not true. Zig places a strong emphasis on memory safety, it just does so in a way that's very different from either Java's or Rust's. I wrote more about this here: https://news.ycombinator.com/item?id=24293329

> It does so with runtime checks that are turned on in development and testing and turned off -- either globally or per code unit -- in production.

This isn't “memory safety”, with this reasoning you could say “C is memory safe if you use ASAN during debug”: it is exactly equivalent except Zig checks are less powerful than the full suite of existing sanitizers for C, but it's enabled by default in debug mode, which is nice.

Re: Interview with Zig language creator Andrew Kelley [video]

#57

Post by littlestymaar »

pron wrote: post #2

I think that Zig's simplicity hides how revolutionary it is, both in design and in potential. It reminded me of my impression of Scheme when I first learned it over twenty years ago. You can learn the language in a day, but it takes a while to realize how exceptionally powerful it is. But it's not just its radical design that's interesting from an academic perspective; I also think that its practical goals align with…

> What a truly inspiring language

It's indeed an inspiring language, and rust is taking inspiration from it already: https://github.com/jswrenn/project-safe-transmute/blob/rfc/r...

> lack of generics

I can't wait before Zig2 comes and eventually adds generics…

Re: Interview with Zig language creator Andrew Kelley [video]

#58

Post by bigbizisverywyz »

pron wrote: post #2

I think that Zig's simplicity hides how revolutionary it is, both in design and in potential. It reminded me of my impression of Scheme when I first learned it over twenty years ago. You can learn the language in a day, but it takes a while to realize how exceptionally powerful it is. But it's not just its radical design that's interesting from an academic perspective; I also think that its practical goals align with…

> ...lack of macros and lack of generics ... To be fair, you can do absolutely everything you want to do in C++ without using either of these features at all, it just takes a bit of discipline.

And if you see the flack that go gets for not including generics then I'm not so sure that that is a great way to get people to adopt your language.

Re: Interview with Zig language creator Andrew Kelley [video]

#59

Post by HourglassFR »

I've stumbled upon the Zig language a while back and have been checking in regularly to follow its progress. Recently I took the time to write a very small program to get a feeling for it. My thoughts :

- It's a very low level language. Having written mostly Python for the past few years, it is quite the contrast. I had to force myself to think in C to get the train going

- Getting my head around the error handling took more time than I'm willing to admit. In the end, it's like having exception but being more explicit about it. It feels nice when you get the hang of it

- The documentation of the standard library is severly lacking, to be fair the language is still very young. More worrysome, it feels very cluncky.

- No proper string support. It is sad that a modern language still goes down that route after Python has shown that correcting this is both definitely worthwhile and a word of pain.

- I have the feeling that optional and error union types are a bit redundant, but I have not written enough Zig to have a real intuition on that. Maybe it is just that I understand monads now.

Re: Interview with Zig language creator Andrew Kelley [video]

#60

Post by ikskuh »

notacoward wrote: post #8
enriquto wrote: post #6

Earlier quoted context omitted.

> I think that our community's equivalent of "where's my flying car?" is "where's my higher-level language?" Ηelicopters are flying cars and they are everywhere for you to use. But some people prefer to use a bicycle to commute to work, rather than an helicopter. I'd even say that most people would prefer to take a bicycle every day than an helicopter. The same thing with lower level languages. Sometimes you do not w…

> Sometimes you do not want to be burdened by the limitations of a "high-level" language. I see very few people suffering from such burdens, but a great many suffering from its exact opposite: using a low- or mid-level language to write hundreds of lines where ten lines in a higher-level language would suffice and be more easily verified as correct.

> I see very few people suffering from such burdens, but a great many suffering from its exact opposite: using a low- or mid-level language to write hundreds of lines where ten lines in a higher-level language would suffice and be more easily verified as correct.

I see a huge load of people suffering from those burdens. Higher-level languages tend to be less efficient and less optimal. Yes, they take a burden from the programmer and move that burden onto the end user.

So the programmer is having the easy life, while every user now waits a second longer for the program startup, a second longer for opening the file dialog, and so on. Doesn't sound much, but if you think about it: Worst case is: 1 programmer shaved off two weeks of work on an app that is used by every person on the planet. 7 billion users lost 1 second. In total, humanity lost roughly 200 years of productive time when every person starts the app exactly once.

Modern computers are incredibly fast and we as programmers use that brutal power to be more lazy than before instead of leveraging that power to all of the users of our tools. We could have systems that go from clicking the power button to being readily available for use in less than seconds. Think about this when you chose a high level language that exchanges programmer convenience for runtime cost and think about if it other peoples time is worth your lazyness.

disclaimer: don't take it personally, i'm just frustrated about imperformant software

Post reply on HN