111–120 of 127 posts
Earlier quoted context omitted.
May you always work with clever programmers who make clever code simple.
Most "clever" programmers makes code a lot more complicated than it should be to show how "clever" they are. The more complicated the language, the more complicated code they will produce. I've seen this a lot of times.
> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?
I've seen this on a modded Minecraft server with a half dozen players connected. It would thrash over a gigabyte of memory every 5-10 seconds or so. I had to tweak the garbage collector to avoid performance hitches.
Earlier quoted context omitted.
> Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? Can someone explain to me what async/await is, in the context of a language like Go? I've used Rust a fair amount, but Go has been my native language for ~5 years now. With that…
> Again, I use Rust and Go similarly in this post because Go is my frame of reference. I thought they were the same on this front, though. No? No. Rust used to have a green threads runtime like Go (and Erlang/BEAM, Haskell, etc.) but that was removed before the 1.0 release. So today, a thread in Rust is a heavyweight OS thread, like in C/Java and most mainstream languages.
Sure the implementation of the threading differs greatly, but I was mainly referring to that I can spawn async behavior, and use synchronous blocking methods to get data back from that async behavior - AND encapsulate it.
All of these are very different than, say, what JavaScript goes through anytime async is involved.
Earlier quoted context omitted.
> Again, I use Rust and Go similarly in this post because Go is my frame of reference. I thought they were the same on this front, though. No? No. Rust used to have a green threads runtime like Go (and Erlang/BEAM, Haskell, etc.) but that was removed before the 1.0 release. So today, a thread in Rust is a heavyweight OS thread, like in C/Java and most mainstream languages.
Yea, I'm aware - but you can spin off a async execution and then send data back over channels (I forget what Rust calls) , as well as wrap that whole thing up in a function with a return value so that the caller has no idea of the threaded execution taking place. Right? Sure the implementation of the threading differs greatly, but I was mainly referring to that I can spawn async behavior, and use synchronous blocking…
Earlier quoted context omitted.
Ah, right. I guess I have seen this sort of thing in Haskell then as well. When implemented with HKTs it usually gets really messy with things like monad transformers, so I prefer to think of asynchronicity more in terms of continuations.
I find monad transformers much clearer than continuations; a monad transformer stack tells you exactly how your effects are going to be interleaved, which is necessarily complex, whereas a continuation could be doing anything at all, the way I see it.
The difference is not that continuations allow anything at all, but that your effects are commutative rather than layered like a monad transformer stack.
Earlier quoted context omitted.
> That's not how I understood it at all. I always assumed that it just promoted explicitly acknowledging when the effect of an async block would be present, but that the normal yield points (traditionally syscalls and IO requests in OS threads) generally still held for the actual execution of the other code. Put it this way: the language implementation won't preempt you except at your explicit yield points (some stan…
I think I see what's going on here. You're answering "in the context of Go" (which is correct, and what was corrected) and I'm interpreting it as a general statement about what async/await mean as general concepts (i.e. in other languages as well). My mistake, I wasn't paying close enough attention. :)
> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.
Many Rust programmers never learned C, or have only a cursory understanding of it. Most C++ people I talk to would strongly disagree that in C++, you should do things the C way.
Earlier quoted context omitted.
I find monad transformers much clearer than continuations; a monad transformer stack tells you exactly how your effects are going to be interleaved, which is necessarily complex, whereas a continuation could be doing anything at all, the way I see it.
No, continuations can be controlled similarly through effect polymorphism, which is what I was trying to describe. The difference is not that continuations allow anything at all, but that your effects are commutative rather than layered like a monad transformer stack.
Fair enough, but you're effectively talking about a secondary, novel type system, right? One of the things I like about monads is that they can be just plain old values of plain old datatypes.
> The difference is not that continuations allow anything at all, but that your effects are commutative rather than layered like a monad transformer stack.
Yeah, monad transformers do feel overly cumbersome for the cases where effects do commute. The trouble is that some effects don't commute, and I've yet to see a formalism that had a good solution to distinguishing effects that commute from those that don't. (I read a paper about a tensor product construct once, but couldn't really follow how it was supposed to work in practice)
Earlier quoted context omitted.
> Most probably their Java code was FUBAR. And so what? If a language's natural form leads to FUBAR code, what else is to blame?
Really? You can write FUBAR code in any language, language has nothing to do with this.
> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?
Three things: * Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves. * Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code. * A tracing garbage collector needs about five times as much memory as explicit freeing to reach the…
Your fourth point is the primary reason.
The GC in the JVM is set to try to waste as much RAM as possible. If you tune the GC you can get a big improvement and the standard Java Frameworks are bloated and slow as hell.
In my opinion it's a platform that is bad by default and simply isn't worth using but companies don't care and just buy more RAM.