ARRI has a specific look and almost perfect directly out of the camera. Compare it to Red or Sony Venice and you see that it is the most appealing. You can make other cameras look like it, but ARRI is just industry standard and produces amazing colors. Their sensor is just fantastic.
Red V-Raptor S35 XL has 16.5 stops of dynamic range with 250-12,800 ISO.
ARRI Alexa 35 has 17 stops of range with 160-6400 ISO.
Both use rolling shutters, both have native ISO of 800. Alexa has better low light noise reduction at higher ISO, but Alexa is sharper and has better dynamic range in low light since it uses 8K to 4K down sampling.
The real difference is in the colour straight out of the chip and how the workflow is for DIT on set.
THe major difference I think is that Arri is already easy to use and slots in to the Hollywood human knowledge base and workflows while RED was mostly used by indie filmmakers, documentarians, Youtubers, and Silicon valley people (if you work at Apple in the US you can buy RED cameras cheaply through company benefits). This pretty much created a different culture of what images should look like around the two cameras. an Alexa camera sets you back close to 80K and a fully equiped RED sets you back about 44K. So its easier to buy it and use it while hollywood rents it on the day for the shoots.
You can get a RED to look like it was shot on Alexa and vice versa in post processing today, but the people who work with the different cameras have different cultures of what is "cinematic" image.
I wonder what the breakdown of software used for VFX is in this report? There are tools like Adobe After Effects that doesn't run in Linux. I know about Fusion and Nuke, but wish the report recorded what software was being run on each OS.
The problem I have with articles like these is that my definition of Web3 is quite a bit different. I tend to lump "crypto" more with NFTs, wild speculation, scams, heavily VC backed "decentralized" tokens, etc. But on the other hand, I want social networks not owned by businesses, I want other major utilities also not owned by major companies (I think gmail is used for 8bn addresses). I think the fediverse is nice start, but still not decentralized enough (a single mastadon server admin can kill it anytime they want or change the rules). In my opinion the definition of web3 is:
"Web3 represents a fundamental evolution of the internet built upon blockchain architectures. Moving from centralized control and capitalization to a decentralized network where the capital is distributed between the operators and consumers."
I feel like the definition of Web3 is hijacked by pundits. Probably because it has become yet another buzzword and being so tightly associated with Crypto maybe has it tainted forever?
What you're describing sounds like the (now unfashionably old and un-hyped as a category) `dWeb` ecosystem. As far as I've seen, 'web3' has meant "websites that use crypto wallets for login and store data in a blockchain and/or IPFS."
The difference between the two isn't necessarily technical; rather it's the requirement that you "join the crypto economy" and start buying up whatever shitcoin -- or CDS-style derivative of multiple coins -- is being used for that one website...and somehow that means "SSO is easy now!" and "anyone can make micropayments anywhere!" etc., etc.
The latter only makes sense in a world of free money from VCs that lets people spend tens of millions of dollars building a *login form* that they charge other websites to use. Their business model seemingly ignores the fact that no serious enterprise[^1] is going to run their internal authN/Z and IdM on a global blockchain.
[^1]: actually, I'm sure several companies have/will tried this, and equally certain the net result was a flaky service that was effectively just querying a Postgres table that cached the on-chain identity for a user and checking their presented token against that. I.e., yet another Postgres instance masquerading as "web3 infrastructure".
Web3 is an attempt to paint scammy technologies (crypto assets) as something useful (decentralized tech).
The truth is: you don't need crypto stuff to have a decentralized internet, as ActivityPub is handsomely showing and, let's be real here, the web itself is showing for the last decades.
I'm still to see a Web3 business that doesn't smell, looks, and behaves like it's a grift.
I never understood the need for "web3" because as far as care "dapps" seems to cover anything non-financial/payment in "crypto".
Blockstacks was initially release with "decentralized" storage that allows me to interact with dapps that would use that storage to hold my data. To me that was and still is the pattern of what I consider "web3".
"Web3" conveniently allows proponents to say "hey the web took a while to catch on" and use that as an argument for the inevitable success of these systems. The connection in naming is essential.
I really, really hope that we can "reclaim" that definition of web3 (which, from what I can tell, was the original one, hijacked by cryptocurrency proponents as the scams mounted and the value of Bitcoin rose in the last few years) as the cryptocurrency sphere collapses in on itself, because I'm right there with you on the desperate need for genuine decentralized internet and societal infrastructure. (I'm deeply, deeply skeptical that blockchain is going to be any meaningful help in this, but the basic problem and the general outline of the solution, I agree with.)
It's extremely useful to have a term like "Web3" to use as a unifying force within such an effort, as well as a way to describe it to people outside, and I don't see a better one for such a decentralization right now.
This is the problem I have with Erlang developers. They only want to work on Erlang. Pragmatism be damned. It is never about the product or the company. It is only about which of the remaining 20 Erlang expert personalities in the world do they get to work alongside with. If there needs to be a special library, all other existing ones are garbage unless written by one of the 20 above, so they will just write their own. I hate to stereotype here, but I would never ever (again) bet my company on Erlang. It is insanely difficult to recruit for. They are truly some of the best developers in the world, but lack pragmatism for problems and every one problem can only be solved with functional programming using Erlang. In my experience, Erlang developers are Zealots for the language and nothing else. If your company decides to pivot away from Erlang to another more accessible language, say Go, you are likely to lose them all.
"Yes, we are going to make your job six times less efficient and substantially more difficult, while simultaneously removing your main incentive for working here. No, you will not receive a raise or any other form of olive branch from us, management, in exchange for the fact that we have measurably reduced your quality of life. No, we are not negotiating this."
If any job I ever had did this, technical or otherwise, I'd leave too. Especially if you were going to rub salt in the wound and pick Go. It's akin to making someone mine coal with a rock instead of a machine.
I think this comment actually unintentionally is reinforcing his point.
Other programming languages than Erlang exist for a reason, they're not just fun toy languages for low IQ folks. There are tons of reasons why Erlang may not be a good fit for some project, and one of these other lesser languages would be a better fit, and he doesn't want to work with people who wouldn't even consider something like that.
1. either the person who asked this question doesn't understand that most of the utility in this ecosystem comes from the BEAM VM, the OTP, and the community around them, not just from the Erlang-the-programming-language.
2. or he/she employs the sunk cost fallacy here: I already invested time into learning Erlang and its Prolog-inspired syntax, so "screw Elixir". Disclaimer: I mistakenly avoided learning Elixir for this reason, simply because I already had lots of Erlang/OTP code already written over the years.
I don't even like Erlang. I'm just pointing out that removing the main incentive for being there for an employee without giving them something in return is naturally going to cause them to bail. You don't spit in a person's face and expect them to be happy about it.
> There are tons of reasons why Erlang may not be a good fit for some project, and one of these other lesser languages would be a better fit
But that's not what they said. The statement was literally "to pivot away from erlang". Imagine you are working with, say, python (which I don't really like but it's a popular example) and were forced to switch to Visual Basic.
I'd count myself as an Erlang developer. But where I worked, we didn't hire many people who had used Erlang before; and I didn't either. It's a small language, and it doesn't take too long for someone who's done a couple languages before to be productive and/or dangerous in it. Yes, immutable is a change; yes, recursion instead of loops is a mindfuck; Yes, a smart person can figure it out and deal. Personally, I loved the promise of Elixir --- BEAM with syntax that's better than Erlang, but I was hoping for different syntax, so I'm out; but it's fine, it seems to be a gravity well drawing people into BEAM, which is a good thing, IMHO.
I'm not going to reach for libraries in Erlang, because mostly I've seen them not be there, and a lot of stuff is almost the same amount of code and fuss to use a library as to build the portion of the library that's actually needed in the moment. Any code that you bring in is code that you're running and responsible for, so it's got to be worth it. I've pulled in libraries that needed a lot of rewriting, and sometimes that's better than starting from scratch, and sometimes it's not. There's a fair amount of stuff out there where someone scratched their itch and left it as is; which is fine and thank you, but it might need a lot of help to be run in a production capacity.
I'm working a new job now and there's probably no Erlang in it. Which is sad, but I'll deal. That said, if I was working in Erlang and management said we had to switch, I would be out. It's one thing to work without the benefits of Erlang, it's another to be working with them and then have it taken away.
If it makes you feel better, a lot of COBOL programmers actually wish it was extinct, because some of the systems they're maintaining are multiple decades old by now.
I suspect that if it wasn't for the virtualization drive behind 5G, Erlang would follow suit as a highly paid legacy language.
As it is, since many legacy telco systems are actually being replaced entirely by virtualized solutions, I see older companies still developing in it, but all hedging their bets on other things (I already mentioned C++ in another thread, but Go and Rust, backed by suitable frameworks that employ Raft and other sync/HA protocols, seem to be in the forefront).
> If your company decides to pivot away from Erlang to another more accessible language, say Go, you are likely to lose them all.
I was sympathizing until that final sentence. I'm not an Erlang programmer, but from what I know about both Erlang and Go, that seems like a terrible jump to make. Of course it depends on other circumstances in this hypothetical as well, but I probably would at least take this as an opportunity to reevaluate my current working situation as well.
Helix just has better out of the box experience. Will take you like 5 minutes to setup instead of 1.5 weeks. It is just so much easier to start a model editor if you havent used one before.
Love this!!! I am huge DaVinci fan because it runs cross-platform (yes linux too). The price is amazing for such a high quality product. Need to see what you really can do on the iPad, I doubt the VFX stuff is there. But this is great.
That's very harsh. If it were a bunch of cobbled together perl and bash scripts I could understand poopooing the software stack, but java for enterprise accounting software is a super common stack and arguably one of the most suitable solution for this type of software.
Or Kotlin. People usually complain about JVM but lots of enterprise software runs on it. Spring boot ecosystem provides lots ready to use libraries. Kotlin can be much easier to use compared to Java.
Yes Go can be better language now, but still lacks lots of library and API support. And Rust, I'd rather code in jvm language fast and ship it fast than building up whole infrastructure that takes way more time to implement.
In my main gig we run on kotlin (fintech/accounting saas) and I absolutely despise it, the overhead is massive. But I wouldn't want to write it in golang, we really need proper OOP. It's also so unbearably slow, it's actually impressive. But it is what it is ¯\_(ツ)_/¯
Also, to be fair, a big part of the slowness is also the tooling, Spring Boot, Hibernate etc. You can mitigate that by using micronaut or exposed/krush, but we only have a microservice running on that. The main business logic is the classic java web stack. Tests, running the app, building takes forever.
It is just my preference. But your right, java is very "enterprise" hence my trepidation. I think there are much better enterprise worthy languages now, like Go. Which are far easier to develop and maintain.
I'm not the OP, but generally JVM applications are very resource hungry under small loads, although I will concede this matters less as load increases, and the extreme OOP style of programming that Java encourages, in my opinion, leads to a lot of faults that require more operational babysitting than I'm ok with.
I don't have any empirical evidence, just experience. As such I'm very biased against it.
Java was great at the time it was created. But now, I think there are several better languages that are more suited for today. Like Go as an example. Easy to develop and easy to maintain. You get very good performance for little effort. It is just my personal preference, but I don't care to maintain Java or JVM anymore. FWIW, I was at the very first every Java One conference. Have used it for many years.
It might make sense to revisit your stance given the most recent JEPs that have been introduced. Java 19 introduced virtual threads and structured concurrency, which will arguably make Java + the JVM a great alternative to Go, etc. Especially since it's very backward compatible.
W/ Graal as well, the AOT compilation comes 90% of JIT performance.
I really think the JVM is an exciting eco-system that has a very bright future if it keeps going the way it is. Brian Goetz' "Paving the on-ramp" discusses how to reduce the boilerplate even further. So these things are definitely a priority for the Java/JVM team[0].
It's GPL with the 'classpath exception' so that you're even exempt from the GPL the you link. Seems pretty good licensing? Do you prefer even more permissive than that?
This is no longer a real reason. It's licensed as GPL with a "classpath exception." That's pretty permissive and this article[0] does a pretty good job of explaining some questions you may have.
Keep in mind that most options have an expiration date on when they can be purchased after the employee no longer works at the company. Furthermore most option agreements have a ROFR clause. I would say let them have the options. There is good chance they might not even execute them in the required window.
I would love this if it wasn't also built on the Java runtime. I hoped the "from ground up" rewrite to include a new much more performant backend that didn't burn resources. To be fair, I even think VSCode is too slow. I have been loving Helix Editor since it gives a great out-of-the box experience for terminal. But craving a better VSCode replacement. Had high hopes for Fleet, but I guess you can't teach an old dog new tricks.
I've been liking https://zed.dev/ for something that gives me more smarts out of the box than Sublime Text but maintains the responsiveness. Limited set of languages but it supports the ones I use on the daily
