Hacker Newsnew | past | comments | ask | show | jobs | submit | mordnis's commentslogin

I have the same opinion. This is just a normal conversation. If I'm not doing this, I either want to rant to someone or I'm in a so hostile conversation that it doesn't make sense to do it.

Is the battery life better with Graphene?

I would say, similar. In theory it may be slightly worse, because you are not using play services to deliver notifications, but each app does their own fetching (I believe that's how it works), but you will also restrict apps more (due to e.g. being able to restrict network access), so the two sort of cancel out.

Yes unless the app offers Unified Push (like Molly vs Signal).

I see. Thanks for the feedback!

Couldn't the same thing be said about functions that accept allocators?

I start to want a Reader Monad stack for all the stuff I need to thread through all functions.

Yeah, these kinds of "orthogonal" things that you want to set up "on the outside" and then have affect the "inner" code (like allocators, "io" in this case, and maybe also presence/absence of GC, etc.) all seem to cry out for something like Lisp dynamic variables.

A few languages have those, and I don't miss them, because in large codebases it becomes a pain to debug.

xBase, Clipper, Perl, Tcl upvars


It depends on how you do it. XSLT 2.0 had <xsl:tunnel>, where you still had to declare them explicitly as function (well, template) parameters, just with a flag. No explicit control over levels, you just get the most recent one that someone has passed with <xsl:with-param tunnel="yes"> with the matching qualified name.

For something like Zig, it would make sense to go one step further and require them to be declared to be passed, i.e. no "tunneling" through interleaving non-Io functions. But it could still automatically match them e.g. by types, so that any argument of type Io, if marked with some keyword to indicate explicit propagation, would be automatically passed to a call that requires one.


that's basically implicit parameters, the typed, well behaved version of dynamic scoping.

Yep, I believe that's what Scala called that.

And I think we need something like this to get people off globals.


I don't think so because the result of calling an allocator is either you got memory or you don’t, while the IO here will be “it depends”

I don't get it, what's the difference between "got or don't" vs "it depends"?

The allocator’s output is only two: either you get memory or you don’t. To quote GP

> Every function with an IO interface cannot be reasoned about locally because of unexpected interactions with the io parameter input

This means with IO interface is not quiet clear what WILL happen so it “depends”


Useful info. Thanks for sharing!


Well, for example, every function that allocates expects allocator as an argument, it is not abstracted away. Resource deallocation is not abstracted away, you have to explicitly free your resources. Ever function that uses IO expects it as an argument. It doesn't have operator overloading, which is also an abstraction.

It is a very explicit language.


I left the "mostly" in my comment because custom allocators is one area where Rust as an ecosystem is still in need of some work, and I'm aware of that - hell, in part because of TigerBeetle's blog posts on the subject.

Everything you're describing is a stylistic preference, though - and doesn't contribute to bloat, which is what the parent comment was implying. If your program is bloated, that's on you to clean up - it doesn't matter if it's in C, C++, Rust, or Zig. Every single one of these languages has nothing that stops you from getting it right.

(A weird aside but the downvotes on this chain are just odd to me. I'm not telling y'all to not write Zig, chill already)


Look, I'm working on an async I/O engine, not unsimilar to Tokio. I started running benchmarks only to realize that I'm significantly faster than Tokio. Go, which is a garbage collected language with preemptive scheduling, is also faster than Tokio on these benchmarks. And Tokio is fast, I'm not claiming it's not. Rust developers program in terms of traits, and borrow checker behaviours. That's fine if you want enterprise kind of safety by tooling. It's just not enjoyable to me and that seems fairly common view. There are people who enjoy languages like Rust, Scala, Haskell. They allow you to create your own world in the type system and that's fine, but it is more disconnected from the actual computer the code is running on.


> I started running benchmarks only to realize that I'm significantly faster than Tokio.

In single threaded, sure. To my knowledge you're not faster in multi-threaded contexts.

> Rust developers program in terms of traits, and borrow checker behaviours.

You don't have to do that, though. People have experimented with other approaches besides what you see in e.g tokio.


I was hacking on a thing in Rust that beat Tokio pretty significantly in some benchmarks. There seems to be a lot of overhead introduced by it.


Local allocators are also in the works for Rust, as well as a general effect system (including potentially an IO effect). Rust also doesn't have fully general operator overloading, it currently uses traits instead. (Though explicit local notations are generally a better way of handling operator semantics, and a future edition of Rust could potentially achieve this via macros.)


Zig can also be annoying. For example, you cannot just ignore the return value, even in debug builds. Playing around with slices, c strings, arrays is also annoying in comparison to C.


I feel that way as well. When I'm thinking about what I like and dislike, it just makes me procrastinate and feel miserable. Life is much more enjoyable when I think about duties I have and how to fulfill them.


Heh, my wife was recently telling a story about how she taught our son how to run into a hug. She did not, I actually did, but I let her have it since she was so excited about it.


Maybe we should have no government, because they always have some information on us which can be abused


Well, of course not. We agree that some types of violence are okay, like police or military using violence for police and military things. I'm sure he wouldn't have posted that if people were cheering that a serial rapist has been shot by the police.


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

Search: