4 ms·
So I found this analogy a little shallow. The tl;dr is: Some languages are dynamic (Lua being ht example here but obviously there are many others eg Python). T
by cletus 7y ago
So I found this analogy a little shallow. The tl;dr is:
Some languages are dynamic (Lua being ht example here but obviously there are many others eg Python). The author then chooses to differentiate types of statically typed languages to those with generics (Rust being the example) and those that don't (Go being the example).
I'm not sure that's a useful distinction because all type systems have limitations and there are many orthogonal dimensions. A language can have (or not) generic types while separately being able to define enumerated types (or not), as just one example.
The interesting thing (at least to me) about Rust is that Rust goes beyond describing types to describing (at compile-time) ownership of data. There is a developer cost to this and a compile-time cost. Personally my view is:
- Compile time errors are cheaper to debug and fix than run-time errors. That's the whole point of having a type system: to catch errors at compile-time. Better that than a segfault. Rust is novel in that it eliminates a whole class of problems with data ownership, lifetimes and access. Not every problem of course.
- Memory-safety is just too important such that Rust will increasingly fill a niche because this is just too easy to get wrong in, say, C/C++.
You do have to jump through hoops go properly describe ownership semantics so the Rust compiler can satisfy safety constraints. Like a type system, there are limitations to this and you can intuitively come up with examples that you know are safe but are hard if not impossible to describe to Rust. Rust does get better with this as time goes on.
Whatever the case, I'm very bullish on Rust.
- rvz 7y agoWell as much as Rust covers all the main benefits and features compared to other languages, some companies can afford to switch to it but others think more carefully if such a switch is more trouble that it’s worth. It no doubt that the barrier to reading / learning Rust is still higher compared to other languages despite the languages safety guarantees and performance. It is still a new language that some large companies can afford to invest their time using it. However if a senior dev that pushes for a rust codebase and ends up leaving the project, the team would probably revert back to the second-best language that everyone knows rather than continue. It doesn’t make any sense to use Rust for the sake of Rust or even strangely: “because everyone else is using it”. Even as a Rust user myself, the author has failed to mention about the quality of the crates ecosystem which mostly still have pre-1.0 libraries and aren’t even stable yet and even a popular few had and still have unsafely issues. In a typical production software house of 2025 for new server-side software, I would use Rust over C++ and JavaScript (Node). But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some companies over Rust due to leveraging the existing Java ecosystem and being a safer alternative to Java.
- zelly 7y ago> But for 2020? Kotlin/Kotlin Native sounds like a safer bet for some companies over Rust due to leveraging the existing Java ecosystem and being a safer alternative to Java. You should consider plain Java tbh. Java 15+ is basically Kotlin anyway at this point. It's much easier to hire or outsource Java developers.
- carlmr 7y agoIt's easier to find Java devs, but whenever I've been in contact with any they're also on average the lowest quality developers you can find. It's the language everybody learned at uni, so you get a lot of people that never did more than the bare minimum.
- pjmlp 7y agoJust like any other language. Are you aware that there are outsourcing projects doing Haskell, Scala and C++ as well. Hint, the deliverables aren't usually what one would expect from the skill levels usually required by average users of those languages.
- pjmlp 7y agoThis was one of the reasons why NVidia went with Ada/SPARK instead of Rust for their security critical firmware.
- imtringued 7y agoI'm not sure what makes you think an even newer language will solve these problems. Kotlin Native requires you to have a pure Kotlin ecosystem. It's far more likely that Kotlin Native will be superseded by GraalVM's native image feature by updating existing Java libraries to avoid using dynamic features such as reflection and runtime proxies (Hibernate/Jackson/etc).