This person posts an identical comment in every single Blender thread to promote his startup. Check their post history.
I am just wondering, is such a consistent plugging allowed on HN? To me it lowers the quality of the discussion and their posts are often voted to the top on all Blender related posts.
Copy-pasting the identical comment certainly isn't, dang told me so when I was once re-using a comment I made earlier for another thread.
I think it's cool what doctoboggan has done with Blender, I feel it's okay to mention it in every Blender thread, but he should actually post a fresh comment.
And then it's up to us users if we feel it's become a bit stale. Downvoting exists.
You can use Java collections in Scala just as you do in Kotlin, and in fact interop is easier in Scala since you can write typeclass instances for the Java types whereas there's no equivalent for that in Kotlin.
The real difference is that more of the Kotlin ecosystem uses Java's fundamentally mutable collections compared to the Scala ecosystem, and using actually immutable collections in Kotlin is extremely difficult to the point that essentially no-one does it. IMO that's a bad tradeoff in the long term, but you can absolutely take the same approach in Scala if you really want to.
Kotlin doesn't have immutable collection types in the standard library (it lets you use a read-only interface but the collection is really still mutable and will be seen as such by any Java code), so if you want actually immutable collections you have to use non-standard collections, and since Kotlin doesn't have typeclasses or implicit conversions it's difficult to interoperate between any non-standard collection library and other Kotlin code.
Yeah, if all your code and libraries are Kotlin then there's less risk of a collection being mutated under you (though even then, Kotlin gives you no way to write a method that only accepts an immutable collection - you can write a method that accepts a view-only interface, but it will always be possible to pass a mutable collection and mutate it in parallel while that method is running). But of course in that scenario there's also zero benefit from having compatibility with the Java collections.
Kotlin's STDLIB collection types are essentially aliases for the Java types. So while the Scala adapters are low-cost, in Kotlin everything's zero-cost.
One other benefit of that is you maintain object identity. I don't think that Scala's wrappers do that.
Scala has the full suite of Java collections without any conversion or overhead whatsoever.
But it also has Scala collections. With scala collections you get the full power of the Scala type system, as well as a much richer and full featured collections api. So most scala programmers won't bother with java collections unless they have specific java interop requirements.
The Scala adapters are merely ways of converting java collections to scala collections and vice versa.
I think it's a fair complaint that in Scala it is a pain in the ass to deal with Java collections. You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.
No, it's not hard. In Scala, you are completely free to use those java collections and you can do it exactly how kotlin programmers do it. You want a java list, without any need to convert back and forth between Scala and Java? Import `java.util.List`. All of the same methods and iterators and expressions and constructs are still there. You get all of the lack of capabilities and grace that the java collections provide. Literally no different from using the same collections in Kotlin.
The problem is that those java collections suck in comparison to the Scala collections. So Scala programmers prefer to use Scala collections. Scala programmers would never willfully use java collections if they don't have to, and if they absolutely have to, they have minimal overhead conversions back and forth. The minimal conversion overhead is the price they're willing to pay to use better collections while maintaining java interoperability.
Except Kotlin enjoys the compatibility with Java, plus it outfits those java collections with extension methods and some compiler tricks to achieve all the same functionality as the Scala collections (in fact, I would say even more self-consistent and useably than in Scala). Just as in Scala, in Kotlin you can use functional transforations that Scala users are so accustomed to:
Kotlin:
listOf(1,2,3,4)
.map{i -> i + 1}
.filter { it % 2 == 0 }
.flatMap { listOf(it, it * 2, it * 3) }
Kotlin even has a similar take to Scala's views, which they call sequences:
listOf(1,2,3,4)
.asSequence()
.map{i -> i + 1}
.filter { it % 2 == 0 }
.flatMap { listOf(it, it * 2, it * 3) }
.toList()
Is this really so "lacking in capability and grace" compared to Scala? The only think missing is persistent immutable collections, which are implemented in kotlinx.
> The only think missing is persistent immutable collections, which are implemented in kotlinx.
You said:
> You have to litter your whole code with `.asScala` and `.asJava`, the java collections don't work with for comprehensions, etc.
So how does kotlinx achieve zero-cost compatibility with Java collections without having something like `.asKotlin` and `.asJava`? Because otherwise there is no difference between Scala and Kotlin in this regards.
It's only a problem if you can't decide which part of your project to write with which language.
If I have to use Java, I put it into a separate sub-project and make sure that I have a nice API to interface between the subprojects. `.asJava` and `.asScala` then only appear at very specific places where the interop happens.
What you're describing is in and of itself a severe cost and barrier to the very thing we're describing: interoperability between Java and Scala collections. On the one hand you have Scala where you either have to constantly `.asScala` and `.asJava`, or go your route of ensuring that in any given module only deals with either Scala or Java collections. This may involve additional abstractions or classes to achieve. On the other hand you have Kotlin which just directly, frictionlessly deals with Kotlin/Java collections the same way (in fact, they literally are the same). We're comparing "some small-to-medium cost" against "zero-cost".
Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."
> Or an other way of saying it is that your approach of walling off modules as either java-collection or scala-collection is kind of like saying "Java and Scala collections work well together, so long as you don't have to use them together too much. If you minimize how much they need to interoperate, the problem is not so bad."
Yes, that's actually a very good way to rephrase it. That being said; I myself wouldn't limit that to just the collections; Java and Scala on the language level have excellent interop. For Scala-the-ecosystem the story is a bit different.
Java is not the primary target for most of the Scala libraries. Not even a secondary one, I dare say. (I'm not even sure how you would model a Java API for a library - say; Cats - that uses implicits for the heavy lifting.)
That of course stems for the fact that Scala makes use of concepts that have no correspondence in neither Java or Kotlin, so there will necessarily be something lost in translation.
I mean, you do realize that you're writing Java code right? If you want ultimate low level optimization and control then you're already about ten miles too far downstream to make that turn. Also, I'm guessing the copy overhead is more than offset by the JVM being able to do better optimizations around these data structures.
Structs with mutable fields is hardly “ultimate low level optimization”, it’s something a lot of programmers still use as a matter of course. (I say this as a fan of immutable data!)
Ultimate low-level optimization in Java would be more like packing your structure into arrays of integers - which is something people actually do in Java. Just because you’re using Java doesn’t mean you don’t want your code to run as fast as possible.
I don't know if the JVM developers have actually implemented this, but since records are immutable, there's no reason why a copy couldn't share memory between the instances.
The major downside is that could ruin cache locality and make passing the instance across a FFI boundary require a copy.
Another optimization would be that the JIT (or even perhaps javac) could notice cases where you make a copy (with one field changed) of a record and then never use the original reference again. If the JIT (or javac) can prove that no other bit of code holds a reference to the original record, it can reuse and mutate the original one instead of making a copy. I don't know if this optimization is or will be implemented, of course.
Either way, I expect the overhead you mention ends up being worth the benefits of immutable data. (That's been my experience using Scala, anyway.)
This has been argued ad nauseam around the time Scala started gaining traction because scala's collections are grouped into immutable and mutable. The consensus at the time is that the GC overhead is well worth the ability to parallelize computation.
Then you've invented mutability without references/identity. Except those are desired properties for data classes, unlike for value classes which have such semantic difference.
Btw Kotlin allow to make immutable Java records too so clear winner.
Not sure what you're getting at. Immutable means exactly that. If you hand out an object, then do a copy change, that change isn't reflected in the object you gave to another method/thread/fiber/etc. Immutability doesn't mean application state never changes; it means that a single reference will always point to memory that hasn't changed.
Parent means basically the difference between identity and primitive/value classes. In Haskell, you’ve only got the latter (maybe you can manage something with lower level controls exposed), that is in a non-haskell syntax new Point(3,2) == new Point(3,2), even though in memory the two object is different.
“Problem” is with records, that they are only shallowly immutable. record Rect(List<Point> corners) will readily hand out a “pointer” to a mutable list. It can be solved of course by storing only immutable objects.
What parent may have failed to get from grandparent comment is that the latter likely meant it under the hood, transparently to the user. That is, new Point(3,2) != new Point(3,2) but the JVM can make the object reference the same data, because the field itself is final. Thus a copy can be optimized at the JVM level, while still having identity.
Or you know, the JIT will trivially optimize away the old class if it is reassigned to the same variable, as you would use it inside a loop. How do you think the litany of FP languages work? Like Haskell, Scala, Clojure?
False. The JVM already does quite a good job with escape analysis, and record types just add extra semantic information to potentially further improve the situation.
As opposed to what exactly? How would a C program’s memory graph look with quick bursts of memory-allocation requiring functionality, especially if it is very dynamic in nature? Yeah you can overallocate with memory pools and the like, and there are cases of course where escape analysis can’t help — that’s why Valhalla is in the works for quite some times now.
But GC-wise the JVM is far ahead the game, whatever you see is likely better than the same functionality would be under JS, Python, C#, Go, etc (though the latter two do have value types/structs already so they can at some place manually do the “escape-analysis”. But not every problem requires/can use value types either)
That's a theory not happening in practice. In practice Java programs are slow and memory-hungry because of those issues when some people think that it's cheap to create small objects or that escape analysis will solve their issues without verifying that it works for their case.
Java isn’t perfect. But you underestimate the amount of software written in it. Or even things like Python and JS which are a lot more basic but have similar elements in regards to their memory model. What do you use?
I work as Java developer for the last 10 years, I perfectly understand the amount of software and other things.
I don't know much about Python and JS, but I do know that they're not using immutable model, everything is mutable in Python and in JS, so I'm not sure what's your point. The only immutable language I'm aware of is Haskell which is not used widely. Just because JVM is faster than Python or V8 does not mean that it's OK to slow it down with immutables.
1. with possible loss of information
2. as API, but an operator can do more
3. they are surely serializable, but they still need all the ugly reflection hacks that come with that (like bypassing the constructor and allowing the JVM to write to final fields)
4. that part was just presenting a benefit of records (on its own; not over Lombok/Kotlin), but the fact it's under the header "Why Records Are Better*" is confusing
In Quebec City they are loudly proud of how many Anglos they have driven away. They pretty much purged the city of anything non-French in the two last decades and are displaying it as a success story.
For me, displacing large communities based on their mother tongue is nothing to be proud of. Be it either way.
Citation needed? I'll concede that I haven't lived there so I could be wrong, but I've been to Quebec city twice, including once with people who spoke no French at all, and never felt any hostility. Again, I'm not disputing that it could be different for the local Anglo minority, but I'd need to see some sources before I believe that you're not exaggerating.
There’s a difference between a tourist and a local. As a tourist you bring dollars. But try getting any government service in English and you’ll get eye rolls and rude behaviour. Even cops in Montreal will not speak English generally.
Sure, as for literally any other subject, you may find people with extreme views on the topic, but that's what they are: extreme. That doesn't make it the general consensus.
Yes it is. The point is _not_ about driving Anglos (or whatever culture) away, but about being proud of being able to communicate in French. As a matter of fact, exactly the same thing English speakers ask to literally the rest of the world.
Edit: and, of course, this does not apply to tourists or visitors. This point is about people who want to live in Quebec.
It was an exhibition on the top floor of the tallest building in the city. It was comparing Montreal to Quebec City trying to draw more people and business to Quebec City. One of the "selling" points was a statistic saying that:
1. Montreal has about 50/50 French/English split whereas in Quebec City it's something like 98/2 French/English. Yes, that was presented as an advantage.
2. There was a graph showing how the city is becoming more and more French-speaking over time. Again, proudly presenting that fact as a selling point.
I never said they are openly hostile but by hindering any English business and opressive language laws they drove whole communities of English speakers away. That's a fact.
It's funny that most of these super hyped up mechanical keyboards still use traditional staggered non-split layout that will still contribute to developing RSI sooner or later.
I feel bad for the shoulders and hands of all those geeks using their tiny $600 cramped keyboards.
Any keyboard that does not separate into two independent halves (like ErgoDox or Matias ErgoPro) is horrible for posture and ergonomics.
https://shop.keyboard.io/products/model-01-keyboard is my keyboard of choice for most tasks, and certainly for typing. It's both split and ortholinear. It uses Mathias Quiet Click switches and custom-formed keycaps for the design.
nutritionfacts.org is an extremely biased site that has been created by a vegan who built his whole career on speaking about health issues. While it has the word "facts" in its title nothing prevents them from cherry-picking studies to support their original views.
If you cherry-pick different studies you might actually find that consuming large amount of plants stresses our digestive system way more than a fatty steak with potatoes.
> If you cherry-pick different studies you might actually find that consuming large amount of plants stresses our digestive system way more than a fatty steak with potatoes.
You really, REALLY, believe with all information being out there nowadays that a diet of only "fatty steak with potatoes" will be healthier for humans that the "balanced WFPB diet" that is nutritionfacts.org claims is scientifically proven to be the healthiest?
I think you have nothing to back that up. Please cherry pick how you please and present your evidence.
Dr Greger, who started the non-profit nutritionfacts.org, is often attacked for being an ethical vegan. Since people reason that would impair his ability to present unbiased evidence. Though no-one has ever gotten beyond claiming he's cherry picking. I wish someone would describe a different diet that is as well supported by scientific evidence, as what nutritionfacts is doing for WFPB.
There is some scientific evidence building up in for the Keto diet. But that is --as far as I know-- not a diet for life.
On the other hand there is the raw diet movement (basically an uncooked WFPB diet), but that has little scientific and mostly anecdotal evidence.
The keto diet's main difficulties are the prevalence and preponderance of available sugary foods, the near inability to eat socially, and the extreme difficulty in adopting the diet in the first 3 weeks for people regularly consuming 200g+ of carbohydrates a day.
The raw diet is mostly a trendy thing people write about. The bioavailability of nutrients in many raw foods is just too meh.
We know what the best diet is. A plant and fish based diet with small amounts of other meat. Meat that doesn't subsist on a diet primarily of corn or other, less edible things. This diet is completely unsustainable on a global scale and would result in even more ecological havoc.
The discussion between plants or plants + meat is complicated, but for now I'm going to ignore it because there's more important considerations:
- Companies are making our produce harder to digest as they try and make products with a longer shelf life.
- Eating industrially produced meat (of any sort) is very unhealthy and in many ways unsafe.
- This entire discussion removes dairy from the equation, which is a large part of the puzzle for most people.
- The low-carb vegan and the low-carb omnivore are far better off than anyone consuming 200g+ of carbohydrates a day.
> We know what the best diet is. A plant and fish based diet with small amounts of other meat.
Nope. Fish (most fish) as a central part of diet, will contribute a lot to build up of heavy metals in humans. And what is "small amounts of other meat"? 3x per week? This is basically an omnivorous diet. Compared to the SAD is probably just the junk cut out.
This, SAD-processed, is a very unhealthy diet, compared to a balanced WFPB diet. There are lots of studies to back this up.
> - Companies are making our produce harder to digest as they try and make products with a longer shelf life.
Yups.
> - Eating industrially produced meat (of any sort) is very unhealthy and in many ways unsafe.
Not a problem for those eating WFPB.
> - This entire discussion removes dairy from the equation, which is a large part of the puzzle for most people.
The site you linked is thick which propaganda which makes me doubt your bias and arguments. Choosing your sources is important for making a compelling argument.
One man's truth is another's propaganda, what are your sources? (I've shown mine, and I must say it's pretty convincing and lines up with what I already knew about the human body)
I'm not at all saying there's no use for keto, I just think it should never be a mainstream diet (but something applied in specific cases, under medical supervision). As far as sci evidence goes, WFPB seems to be the "best" diet for the human species as a whole.
I am just wondering, is such a consistent plugging allowed on HN? To me it lowers the quality of the discussion and their posts are often voted to the top on all Blender related posts.