Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
> Has the Rust-portability situation been addressed?
The rust portability story is in the process of being addressed, by two different projects:
gcc-rs[0] adds a Rust frontend to GCC.
rustc-codegen-gcc[1] adds a GCC backend to rustc.
Both are progressing pretty well, but it will likely still take a while until they reach maturity.
> Or will this change restrict the number of platforms the Linux kernel will be usable on?
There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature.
> what will the advantages be?
There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely).
As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations.
[0]: https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/
[1]: https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/
> Has the Rust-portability situation been addressed?
The rust portability story is in the process of being addressed, by two different projects:
gcc-rs[0] adds a Rust frontend to GCC.
rustc-codegen-gcc[1] adds a GCC backend to rustc.
Both are progressing pretty well, but it will likely still take a while until they reach maturity.
> Or will this change restrict the number of platforms the Linux kernel will be usable on?
There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature.
> what will the advantages be?
There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely).
As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations.
[0]: https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/
[1]: https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/
> Does anyone have a strong suggestion on which of those official resources I should start with?
The rust book. Reading it start to finish provides a very good basis.
And if you're tempted to "learn by doing" with the usual linked lists, go and read "learning rust with entirely too many linked lists": https://rust-unofficial.github.io/too-many-lists/
Rust has enough rare or novel concepts that trying to learn on the job with no book learning whatsoever is really reserved for the rarefied few. Though I understand that a lot of C and C++ concepts port quite easily, it also differs from those languages (especially C++ for advanced features) that doing a bit of a reset will avoid future pains.
I learned it combining the Book and Rustlings. There's a table in the exercises directory mapping the exercises to the chapters of the book, so I'd every day do the exercises for yesterdays chapter first before todays chapter to have some sort of spaced repetition. For more material, check out https://github.com/jondot/rust-how-do-i-start
That is good to know. But I looked this up and what I've found is Jonathan Corbet saying in 2010 that "occasional" posting of subscriber links is fine.[1]
I am not Jonathan Corbet so I don't know what he considers occasional. But this is the fourth LWN subscriber link posted in the past 7 days, and the eighth in the past 14 days.[2]
For reference, LWN currently lists 10 paywalled posts, the oldest from 13 days ago. So those posted on HN are nearly every paywalled article that they have.
[1] https://news.ycombinator.com/item?id=1966033
[2] https://hn.algolia.com/?dateEnd=1663790400&dateRange=custom&...
[3] https://lwn.net/
AWS wrote Firecracker which powers AWS Lamba - https://github.com/firecracker-microvm/firecracker
I think "better Haskell on JVM" (in contrast to "worse Haskell") is a good identity for Scala to have. (Please note that this is an intentional hyperbole.)
Of course, there are areas where Haskell is stronger than Scala (hint: modularity, crucial for good Software Engineering, is not one of them). And Scala has its own way of doing things, so just imitating Haskell won't work well.
Examples of this "better Haskell" are https://typelevel.org/cats-effect/ and https://zio.dev/ .
All together, Scala may be a better choice for you if you want to do Pure Functional Programming. And is definitely less risky (runs on JVM, Java libraries interop, IntelliJ, easy debugging, etc...).
None of the other languages you mentioned are viable in this sense (if also you want a powerful type system, which rules out Clojure).
I agree that Rust's identity is pretty clear: a modern language for use cases where only C or C++ could have been used before.
I think "better Haskell on JVM" (in contrast to "worse Haskell") is a good identity for Scala to have. (Please note that this is an intentional hyperbole.)
Of course, there are areas where Haskell is stronger than Scala (hint: modularity, crucial for good Software Engineering, is not one of them). And Scala has its own way of doing things, so just imitating Haskell won't work well.
Examples of this "better Haskell" are https://typelevel.org/cats-effect/ and https://zio.dev/ .
All together, Scala may be a better choice for you if you want to do Pure Functional Programming. And is definitely less risky (runs on JVM, Java libraries interop, IntelliJ, easy debugging, etc...).
None of the other languages you mentioned are viable in this sense (if also you want a powerful type system, which rules out Clojure).
I agree that Rust's identity is pretty clear: a modern language for use cases where only C or C++ could have been used before.