Live data from Hacker News

Ruby 2.7

ruby-lang.org

41–50 of 68 posts

Re: Ruby 2.7

#41
post #5
post #4

Earlier quoted context omitted.

I’d love to, if it helps with things like Either/Maybe types. Although from what I’ve looked at briefly the syntax felt a little less intuitive than I’ve seen in other languages. Will have to properly try it out.

what's the purpose of Either and Maybe in a dynamically typed language?

How are they related at all?

Re: Ruby 2.7

#42
post #33

The compaction GC was the most important change. I haven't measured Ruby's performance specifically but in general the difference and improvements over a non-compacting GC is so huge. Specially for long running processes.

Its an important change, but not huge, at least not yet: it's not yet integrated in the GC, which means you have to explicitly request it. And most of the fragmentation comes anyway from the allocations heap. That being said, I think this will improve in the coming releases.

Re: Ruby 2.7

#43
post #26

One of the interesting news is that they are now going to start requiring a C99 compiler, instead of only C90. I've been considering to do the same on my own projects. What does HN have to say about this? Is anyone here still working in a context where C99 is not an option? Did anyone else also recently switch to C99? How did it go?

The only modern problem with switching to C99 is Visual Studio on Windows. You have 2 sensible choices: 1) Use clang to build on Windows. 2) Use the subset of C99 which is implemented in Visual Studio (which also requires compiling as C++, which isn't that difficult to handle).

3) Use C++17 with minimal features. This gives you a lot of needed libraries built-in and it is better supported than C99 (due to Windows).

Re: Ruby 2.7

#44
I had wondered why most recent Ruby releases were on Christmas Day and recently found out why. The Ruby creator Matz is religious (LDS), and he considers it a Christmas gift to the community. I thought that was really cool.

Re: Ruby 2.7

#45
post #26

One of the interesting news is that they are now going to start requiring a C99 compiler, instead of only C90. I've been considering to do the same on my own projects. What does HN have to say about this? Is anyone here still working in a context where C99 is not an option? Did anyone else also recently switch to C99? How did it go?

It's now 2019, and as far as I know, MSVC still doesn't have full support for the 20-year-old C99 standard.

So either you restrict yourself to the subset of C99 which MSVC understands (AFAIK, newer MSVC releases understand more and more of the C99 standard), or just decide MSVC is no longer relevant (which is easier now that clang-cl exists; some big projects like Firefox and Chrome went this way, see for instance https://blog.mozilla.org/nfroyd/2019/04/25/an-unexpected-ben...).

Re: Ruby 2.7

#46
post #42
post #33

The compaction GC was the most important change. I haven't measured Ruby's performance specifically but in general the difference and improvements over a non-compacting GC is so huge. Specially for long running processes.

Its an important change, but not huge, at least not yet: it's not yet integrated in the GC, which means you have to explicitly request it. And most of the fragmentation comes anyway from the allocations heap. That being said, I think this will improve in the coming releases.

What criteria should be monitored to request compaction in a long-running process? Is a timer sufficient (at what interval?) or are there other tools available in Ruby to make that decision?

Re: Ruby 2.7

#48
post #34

Earlier quoted context omitted.

Yes I’m aware they’re monads, my primary languages are OCaml and Haskell. I don’t understand what you’re suggesting with Maybe, that sounds like maybe adding some layer of magic onto it? > Yes people can do anything, but usually they follow the rules they're given. Sure, but the primary advantage remains in not having to trust that, not having to write tests for it, and communicating the contract itself inside the co…

> I don’t understand what you’re suggesting with Maybe I’m suggesting adding a trace of where a None value is created and propagated, for debugging purposes. > the primary advantage remains in not having to trust that, not having to write tests for it Is that the primary advantage? I’m not as sure as you seem to be. And of course there’s one huge part of monads that you have to take on trust even in Haskell isn’t the…

>Is that the primary advantage? I’m not as sure as you seem to be.

It's the combination of that and exhaustive pattern matching that I see as the reason to use strongly-typed functional languages.

>No type system is enforcing those.

This is quite different from not having static type checks at all though. At least with static typing I know that bind and fmap have the correct signature, which is certainly not a verification that they follow _all_ the rules they should (though I am a big fan of dependently typed languages too), yet it is still assurance that the function fulfills a basic premise.

>If you’re comfortable trusting someone else is following that rule why is trusting they follow another so alien?

Because I have seem them betray that trust, over and over again, intentionally and unintentionally, though never actively malicious. Type checking is work the compiler can do for me, so I see no reason to do it myself, where I am known to be rather clumsy and stupid and prone to writing bugs and being human.

Re: Ruby 2.7

#49
post #10
post #5

Earlier quoted context omitted.

what's the purpose of Either and Maybe in a dynamically typed language?

Maybe I’ve just been bitten by the functional bug but I find they can communicate intent much better than scattering around null checks or catching exceptions (many of which require reading the source to understand what exceptions you might get). It’s great in large scale projects, which I think is where a dynamic language starts to show its warts.

Yeah I suppose my bigger beef is I just don't like dynamic languages. Perhaps it is in fact a good idea for them, but being someone primarily interested in types, it largely falls into the realm of "don't care."

Re: Ruby 2.7

#50

> Calling a private method with a literal self as the receiver is now allowed. Oof. Call me old fashioned, but I liked the consistency of not being able to call private methods with an explicit receiver. Oh well! The rest of this looks great, thanks Ruby team!

Funny thing: I always bring up how Ruby has private methods while Python doesn't, when toying around with colleagues about languages, etc. well there goes that I guess.

Sidenote: I can't think of a use case where this is a good idea.

Post reply on HN