6 ms·

I think it's more than just the normal amount for advocacy of a new language. Rust isn't the only "newer" language. I don't feel this kind of mentally strung pu

I think it's more than just the normal amount for advocacy of a new language. Rust isn't the only "newer" language. I don't feel this kind of mentally strung pushing of say Kotlin or Scala or Go or, etc from their fans.

bigfishrunning 10mo ago
I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like web services, but its big runtime and its GC rule it out for a lot of (especially very low level or latency-critical) uses -- you don't see Go ported to microcontrollers for instance. I can't speak for Scala, because i don't have experience writing software in it. To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software. As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) Rust is really a breath of fresh air; not because it's easier, but because it codifies and enforces some good habits in ways that other languages don't.
- tonyplee 10mo ago
  Love to see an AI agent to auto transpile C (sqlite, apache, nginx, mariadb, etc) into rust and run all the regression associated tests and perf benchmarks and produce report on the porting processes and perf delta.
  - nindalf 10mo ago
    Sqlite's test suite is closed source, so no one other than the Sqlite authors can attempt that. That said, you may be interested in this attempt by Turso to rewrite Sqlite in Rust (https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-going-all-in https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...). They're not using AI, but they are using some novel ways to test their code.
- shevy-java 10mo ago
  Kotlin won't replace Java. They do not have the same niche.
  - giancarlostoro 10mo ago
    Kotlin's Niche was to replace LEGACY Java with something that builds for older versions of Java but also gives you features and ergonomics not available for those features. There's a ton of super legacy Java out there.
  - locknitpicker 10mo ago
    > Kotlin won't replace Java. They do not have the same niche. Claiming Java has a niche is very funny. I guess the niche is programmable computers? Well done.
- 9rx 10mo ago
  > I think this is because of the gap in its target market Surely that gap has been filled for at least a decade, even if only by Rust itself? Moreover, I am not sure that serves as an explanation as it shows up in the strangest places. As you mention Go: Visit any discussion about Go and you'll find some arbitrary comment about Rust, even though, as you point out, they don't even exist in the same niche; being different tools for different jobs. > Go was originally pitched as a C or C++ replacement It was originally imagined that it would replace C++ for network servers at Google. The servers part was made abundantly clear. In fact, the team behind it expressed quite a lot of surprise that it eventually found a home doing other things as well. > you don't see Go ported to microcontrollers for instance. You don't? https://tinygo.org https://tinygo.org
  - bigfishrunning 10mo ago
    > Surely that gap has been filled for at least a decade, even if only by Rust itself? I think this is the argument made by the "Rust Evangelism Task Force" -- that Rust provides the features that C and C++ are missing. What i meant by "gap" is "the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin". For the record, I do think all of these languages are great; I'm just trying to reason out the "rewrite it in Rust" mantra that has taken hold in many online communities, including this one. > You don't? https://tinygo.org https://tinygo.org I wasn't aware of this, thank you.
    - 9rx 10mo ago
      > the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin What, exactly, does distance mean here? The other explicitly told design consideration for Go was for it to "feel like a dynamically-typed language with statically-typed performance". In other words, the assumption was that Googlers were using C++ for network servers not because of C++, but because something like Python (of which Google was the employer of van Rossum at the time!) was too slow. Go was created to offer something more like Python but with performance more like C++. It was a "C++ replacement" only in the sense that C++ is what Google was using where it was considered the "wrong tool for the job". Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast. Putting things into perspective, the distance between C++ and Go is approximately the same as the distance between C++ and Python. Which is a pretty big distance, I'd say. C, C++, and Rust are much closer. They are all trying to do essentially the same thing, with Rust only standing out from the other two thanks to its at-the-time unique memory model. So it is apparent that we still don't understand "gap" to mean the same thing.
- munksbeer 10mo ago
  Out of interest > As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) does this mean they allow you to tinker around on your own for this, or do you actually then start to deploy things to production written in the new language. After having quite a long career as a programmer, I realised that if I were ever CTO at a startup, unless there was an absolute proven need to switch languages, I'd mandate only a single language for our (back end) stack. The cost of supporting different languages is just too high.
  - bigfishrunning 10mo ago
    I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.
    - locknitpicker 10mo ago
      > I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. This claim does not pass the smell test. Tech sprawl is a widely recognized problem, and dumping codebases each 2-3 years is outright unthinkable and pure madness. It doesn't even come across as resume-driven development because 3 years is not nearly enough to get anyone at a proficient level. This claim is so outlandish that I'm inclined to dismiss it entirely as completely made-up. There is no project manager in the world who would even entertain this thought.
      - bigfishrunning 10mo ago
        Your world seems small -- I never said anything about dumping codebases. If i have a library implemented in Rust, which gets called by a program written in C++ through FFI, and contacts a service which is implemented in python, I don't need to dump or waste any old work. A carpenter that only uses a hammer isn't a very good carpenter; different tools have different strengths and weaknesses.
- vips7L 10mo ago
  There is no chance that Kotlin will replace Java. Java is the platform and Kotlin does change semantics. They’ve developed their own features that don’t align with the platform. Suspend functions vs virtual threads, data classes vs records, Kotlin value classes vs Java value classes. The gap is widening.
  - b40d-48b2-979e 10mo ago
    From my POV having worked at a giant 50,000 person tech org—primarily Java—Kotlin was the kick in the pants that ushered in a lot of changes in the post-Java 11 world. We were on the verge of migrating wholesale to Kotlin after our CTO wrote an internal whitepaper in favor of the direction.
  - arghwhat 10mo ago
    I don't agree. First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade". The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Kotlin's native backend and GraalVM. The widening gap is not at all moving Kotlin further away from Java developers, but is just increasing the reasons to migrate. It is crucially not making interoperability with existing, legacy Java harder, just giving you more toys. Stuff like suspend functions vs. virtual threads only affects decision making in new application code, and you can for all intents and purposes use either depending on whether you're writing new Kotlin libs for a legacy Java app or a Kotlin app using legacy Java libs. The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing. Plus, considering that Android apps were responsible for a very significant portion of actively developed Java (I would assume quite a loand has with Android having gone full Kotlin, a quite significant portion of Java developers will either already have migrated or soon be migrating to follow suit. This will over time affect a quite significant portion of the available skill pool for hiring, which will add additional pressure on enterprise. There will always be Java, but I'd expect a significant portion of actively developed applications (as opposed to maintenance-mode only applications) to slowly migrate to either Kotlin or something else entirely.
- wang_li 10mo ago
  >To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software. This doesn't explain why so many rust activists are going to projects they have no involvement in and demanding they be rewritten in rust. What's happening is that there are progressive minded people who have progressive minded tactics, where they have a cause and everywhere they go they push their cause regardless of whether the places they are going have anything to do with their cause.
  - fauigerzigerk 10mo ago
    Is it really activism though, i.e. a concerted effort to put pressure on project leaders and make actual "demands"? Or is it just the occasional young Rust enthusiast asking questions or making the case for Rust?
    - zavec 10mo ago
      You haven't been getting the checks? Bring that up at our next secret cabal meeting.
      - cozzyd 10mo ago
        They're borrow checks
    - uecker 10mo ago
      Probably something in-between: a self-organizing cult with too much support from industry.
- giancarlostoro 10mo ago
  Carbon is what could someday be a real successor to C++ in my eyes. It actually focuses on being compatible with C++ code similar to how Kotlin can work with Java directly, except it will make a lot more sense once it is stable and usable, I just hope its not a 'forever-project' like Fuchsia.
  - baranul 9mo ago
    Good point. Many of these other languages claim to be "successors", but are really C++ alternatives, that can have very different programming philosophies, goals, and use cases.
- thesz 10mo ago
  > you don't see Go ported to microcontrollers for instance. AVRGo disagrees: https://github.com/avrgo-org/avrgo https://github.com/avrgo-org/avrgo
  - fclairamb 10mo ago
    No commit for 7 years but https://tinygo.org/docs/reference/microcontrollers/ https://tinygo.org/docs/reference/microcontrollers/ is up to date.
    - baranul 9mo ago
      Not sure what you mean, because tinygo is significantly active[1]. [1] https://github.com/tinygo-org/tinygo https://github.com/tinygo-org/tinygo (latest release was a month ago from this post)
- arroquw 10mo ago
  Actually, GO is ported to microcontrollers with Tinygo. Even u-root works on microcontrollers nowadays. For the more bulky processors, there's also tamago.
- locknitpicker 10mo ago
  > I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. The "long history of safety issues" is actually a combination of being extremely successful (the world runs on C and C++) and production software always featuring bugs. The moment Rust started to gain some traction, we immediately started seeing CVEs originating from Rust code.
- lenkite 10mo ago
  Java has features that Kotlin does not have. Virtual Threads and the API's that support then are effectively incompatible with the Kotlin co-routine libraries.
  - simon_void 10mo ago
    technically, Kotlin can use VirtualThreads like it can use any other Java Api (when being compiled to JVM bytecode).[1] If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads. So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines). What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions! My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.) [1] https://void2unit.onrender.com/post/virtualthreads-in-kotlin/ https://void2unit.onrender.com/post/virtualthreads-in-kotlin...
- hulitu 10mo ago
  > Rust is firmly positioned to replace C and C++ I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu, with disastrous consequences. Anyway, without writing the OS in Rust, Rust will always be a second tier language.
  - steveklabnik 10mo ago
    > Until now, the only real world usage was for coreutils in Ubuntu, This is simply not true, there are millions of lines of Rust code running in production at the largest tech companies in the world.
  - School-Cotton 10mo ago
    > I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu I spent five years working at a company (Materialize) whose main product is entirely in Rust. Since then I work at a company (Polar Signals) where sadly I have to use C and Go, but the main backend storage layer is in Rust. And several of our customers use Rust and it would be a show-stopping bug for them if our product stopped working on Rust codebases. Besides all that, plenty of companies you’ve heard of are now writing large amounts of new code in Rust — most notably Meta and Amazon. Large parts of Firefox are in Rust and have been for years. Ubuntu coreutils is underselling it a bit.
halfmatthalfcat 10mo ago
Can I start then with Scala - it's my favorite language and easily has the best of both OO and functional worlds with insanely useful libraries to express code ergonomically. EVERYBODY SHOULD USE IT!
- vips7L 10mo ago
  Nah it’s too complex, has shipped too many breaking changes, and the community sucks.
  - halfmatthalfcat 10mo ago
    Always gotta get my yum yucked.
    - vips7L 10mo ago
      Just been screwed too many times I guess. I do like it more than Kotlin though. The language is powerful.
  - icedchai 10mo ago
    I worked on a Scala project about 15 years ago and it definitely felt overly complex. Similar to early C++, everyone used their own dialect.
shevy-java 10mo ago
Yeah, I agree with this observation. Not sure why Rust is different here though.
morcus 10mo ago
I'm not a Rust evangelist, but I'm glad that Rust evangelists exist. I decided to try it for a medium-sized (~10k LoC) performance sensitive component recently and it has been an absolute joy to use.
- mring33621 10mo ago
  I'm mostly a Java dev, but baby-stepping Rust has been a lot of fun and reminds me, in a very good way, of the feeling I had in the late 90's when I was first learning Java.
benrutter 10mo ago
I think that's true - but I guess Rust and Zig are unique in that list on being new memory-managed languages (i.e. without garbage collectors). Low level memory-managed languages have been C and C++ mostly for a really long time, so I think Rust and Zig probably seem "more new" than the likes of Kotlin, Go, Elixir, Gleam, etc.
webnrrd2k 10mo ago
Yeah, Julia was all the rage for a while, and that kind of disappeared. Some languages, like elixir, stick around with a low-volume, but consistently positive mention on HN. Which makes me want to use it more.
stouset 10mo ago
Go has already more or less won its target market. Rust proponents are still working to convince C and C++ holdouts, who are understandably skeptical given the past several decades of promised replacements that never materialized.
gf000 10mo ago
Rust is absolutely novel in being the first, production-grade memory-safe low-level language.
array_key_first 10mo ago
Well that's because C, and C++, are uniquely awful and Rust can actually take them on. Kotlin doesn't have a strong case for replacing java because java is, well, just fine. At least it's safe. Sure it's, like, slightly inconvenient sometimes. And other languages like Go which originally claimed to take on C and C++ just don't. Go is garbage collected, it's not a real competition. But Rust is different. It's actually safe, and it's actually a real competitor. There's basically zero reason to choose C other than "I know it" or "one of my library author's knows it". Which are both very good reason, but incidently have nothing to do with the language itself.
LexiMax 10mo ago
> I think it's more than just the normal amount for advocacy of a new language. More than C++? More than Java? More than Python?

bigfishrunning 10mo ago

I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like web services, but its big runtime and its GC rule it out for a lot of (especially very low level or latency-critical) uses -- you don't see Go ported to microcontrollers for instance. I can't speak for Scala, because i don't have experience writing software in it. To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software. As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) Rust is really a breath of fresh air; not because it's easier, but because it codifies and enforces some good habits in ways that other languages don't.

tonyplee 10mo ago
Love to see an AI agent to auto transpile C (sqlite, apache, nginx, mariadb, etc) into rust and run all the regression associated tests and perf benchmarks and produce report on the porting processes and perf delta.
- nindalf 10mo ago
  Sqlite's test suite is closed source, so no one other than the Sqlite authors can attempt that. That said, you may be interested in this attempt by Turso to rewrite Sqlite in Rust (https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-going-all-in https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...). They're not using AI, but they are using some novel ways to test their code.
shevy-java 10mo ago
Kotlin won't replace Java. They do not have the same niche.
- giancarlostoro 10mo ago
  Kotlin's Niche was to replace LEGACY Java with something that builds for older versions of Java but also gives you features and ergonomics not available for those features. There's a ton of super legacy Java out there.
- locknitpicker 10mo ago
  > Kotlin won't replace Java. They do not have the same niche. Claiming Java has a niche is very funny. I guess the niche is programmable computers? Well done.
9rx 10mo ago
> I think this is because of the gap in its target market Surely that gap has been filled for at least a decade, even if only by Rust itself? Moreover, I am not sure that serves as an explanation as it shows up in the strangest places. As you mention Go: Visit any discussion about Go and you'll find some arbitrary comment about Rust, even though, as you point out, they don't even exist in the same niche; being different tools for different jobs. > Go was originally pitched as a C or C++ replacement It was originally imagined that it would replace C++ for network servers at Google. The servers part was made abundantly clear. In fact, the team behind it expressed quite a lot of surprise that it eventually found a home doing other things as well. > you don't see Go ported to microcontrollers for instance. You don't? https://tinygo.org https://tinygo.org
- bigfishrunning 10mo ago
  > Surely that gap has been filled for at least a decade, even if only by Rust itself? I think this is the argument made by the "Rust Evangelism Task Force" -- that Rust provides the features that C and C++ are missing. What i meant by "gap" is "the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin". For the record, I do think all of these languages are great; I'm just trying to reason out the "rewrite it in Rust" mantra that has taken hold in many online communities, including this one. > You don't? https://tinygo.org https://tinygo.org I wasn't aware of this, thank you.
  - 9rx 10mo ago
    > the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin What, exactly, does distance mean here? The other explicitly told design consideration for Go was for it to "feel like a dynamically-typed language with statically-typed performance". In other words, the assumption was that Googlers were using C++ for network servers not because of C++, but because something like Python (of which Google was the employer of van Rossum at the time!) was too slow. Go was created to offer something more like Python but with performance more like C++. It was a "C++ replacement" only in the sense that C++ is what Google was using where it was considered the "wrong tool for the job". Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast. Putting things into perspective, the distance between C++ and Go is approximately the same as the distance between C++ and Python. Which is a pretty big distance, I'd say. C, C++, and Rust are much closer. They are all trying to do essentially the same thing, with Rust only standing out from the other two thanks to its at-the-time unique memory model. So it is apparent that we still don't understand "gap" to mean the same thing.
munksbeer 10mo ago
Out of interest > As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) does this mean they allow you to tinker around on your own for this, or do you actually then start to deploy things to production written in the new language. After having quite a long career as a programmer, I realised that if I were ever CTO at a startup, unless there was an absolute proven need to switch languages, I'd mandate only a single language for our (back end) stack. The cost of supporting different languages is just too high.
- bigfishrunning 10mo ago
  I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.
  - locknitpicker 10mo ago
    > I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. This claim does not pass the smell test. Tech sprawl is a widely recognized problem, and dumping codebases each 2-3 years is outright unthinkable and pure madness. It doesn't even come across as resume-driven development because 3 years is not nearly enough to get anyone at a proficient level. This claim is so outlandish that I'm inclined to dismiss it entirely as completely made-up. There is no project manager in the world who would even entertain this thought.
    - bigfishrunning 10mo ago
      Your world seems small -- I never said anything about dumping codebases. If i have a library implemented in Rust, which gets called by a program written in C++ through FFI, and contacts a service which is implemented in python, I don't need to dump or waste any old work. A carpenter that only uses a hammer isn't a very good carpenter; different tools have different strengths and weaknesses.
vips7L 10mo ago
There is no chance that Kotlin will replace Java. Java is the platform and Kotlin does change semantics. They’ve developed their own features that don’t align with the platform. Suspend functions vs virtual threads, data classes vs records, Kotlin value classes vs Java value classes. The gap is widening.
- b40d-48b2-979e 10mo ago
  From my POV having worked at a giant 50,000 person tech org—primarily Java—Kotlin was the kick in the pants that ushered in a lot of changes in the post-Java 11 world. We were on the verge of migrating wholesale to Kotlin after our CTO wrote an internal whitepaper in favor of the direction.
- arghwhat 10mo ago
  I don't agree. First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade". The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Kotlin's native backend and GraalVM. The widening gap is not at all moving Kotlin further away from Java developers, but is just increasing the reasons to migrate. It is crucially not making interoperability with existing, legacy Java harder, just giving you more toys. Stuff like suspend functions vs. virtual threads only affects decision making in new application code, and you can for all intents and purposes use either depending on whether you're writing new Kotlin libs for a legacy Java app or a Kotlin app using legacy Java libs. The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing. Plus, considering that Android apps were responsible for a very significant portion of actively developed Java (I would assume quite a loand has with Android having gone full Kotlin, a quite significant portion of Java developers will either already have migrated or soon be migrating to follow suit. This will over time affect a quite significant portion of the available skill pool for hiring, which will add additional pressure on enterprise. There will always be Java, but I'd expect a significant portion of actively developed applications (as opposed to maintenance-mode only applications) to slowly migrate to either Kotlin or something else entirely.
wang_li 10mo ago
>To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software. This doesn't explain why so many rust activists are going to projects they have no involvement in and demanding they be rewritten in rust. What's happening is that there are progressive minded people who have progressive minded tactics, where they have a cause and everywhere they go they push their cause regardless of whether the places they are going have anything to do with their cause.
- fauigerzigerk 10mo ago
  Is it really activism though, i.e. a concerted effort to put pressure on project leaders and make actual "demands"? Or is it just the occasional young Rust enthusiast asking questions or making the case for Rust?
  - zavec 10mo ago
    You haven't been getting the checks? Bring that up at our next secret cabal meeting.
    - cozzyd 10mo ago
      They're borrow checks
  - uecker 10mo ago
    Probably something in-between: a self-organizing cult with too much support from industry.
giancarlostoro 10mo ago
Carbon is what could someday be a real successor to C++ in my eyes. It actually focuses on being compatible with C++ code similar to how Kotlin can work with Java directly, except it will make a lot more sense once it is stable and usable, I just hope its not a 'forever-project' like Fuchsia.
- baranul 9mo ago
  Good point. Many of these other languages claim to be "successors", but are really C++ alternatives, that can have very different programming philosophies, goals, and use cases.
thesz 10mo ago
> you don't see Go ported to microcontrollers for instance. AVRGo disagrees: https://github.com/avrgo-org/avrgo https://github.com/avrgo-org/avrgo
- fclairamb 10mo ago
  No commit for 7 years but https://tinygo.org/docs/reference/microcontrollers/ https://tinygo.org/docs/reference/microcontrollers/ is up to date.
  - baranul 9mo ago
    Not sure what you mean, because tinygo is significantly active[1]. [1] https://github.com/tinygo-org/tinygo https://github.com/tinygo-org/tinygo (latest release was a month ago from this post)
arroquw 10mo ago
Actually, GO is ported to microcontrollers with Tinygo. Even u-root works on microcontrollers nowadays. For the more bulky processors, there's also tamago.
locknitpicker 10mo ago
> I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. The "long history of safety issues" is actually a combination of being extremely successful (the world runs on C and C++) and production software always featuring bugs. The moment Rust started to gain some traction, we immediately started seeing CVEs originating from Rust code.
lenkite 10mo ago
Java has features that Kotlin does not have. Virtual Threads and the API's that support then are effectively incompatible with the Kotlin co-routine libraries.
- simon_void 10mo ago
  technically, Kotlin can use VirtualThreads like it can use any other Java Api (when being compiled to JVM bytecode).[1] If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads. So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines). What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions! My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.) [1] https://void2unit.onrender.com/post/virtualthreads-in-kotlin/ https://void2unit.onrender.com/post/virtualthreads-in-kotlin...
hulitu 10mo ago
> Rust is firmly positioned to replace C and C++ I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu, with disastrous consequences. Anyway, without writing the OS in Rust, Rust will always be a second tier language.
- steveklabnik 10mo ago
  > Until now, the only real world usage was for coreutils in Ubuntu, This is simply not true, there are millions of lines of Rust code running in production at the largest tech companies in the world.
- School-Cotton 10mo ago
  > I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu I spent five years working at a company (Materialize) whose main product is entirely in Rust. Since then I work at a company (Polar Signals) where sadly I have to use C and Go, but the main backend storage layer is in Rust. And several of our customers use Rust and it would be a show-stopping bug for them if our product stopped working on Rust codebases. Besides all that, plenty of companies you’ve heard of are now writing large amounts of new code in Rust — most notably Meta and Amazon. Large parts of Firefox are in Rust and have been for years. Ubuntu coreutils is underselling it a bit.

halfmatthalfcat 10mo ago

Can I start then with Scala - it's my favorite language and easily has the best of both OO and functional worlds with insanely useful libraries to express code ergonomically. EVERYBODY SHOULD USE IT!

vips7L 10mo ago
Nah it’s too complex, has shipped too many breaking changes, and the community sucks.
- halfmatthalfcat 10mo ago
  Always gotta get my yum yucked.
  - vips7L 10mo ago
    Just been screwed too many times I guess. I do like it more than Kotlin though. The language is powerful.
- icedchai 10mo ago
  I worked on a Scala project about 15 years ago and it definitely felt overly complex. Similar to early C++, everyone used their own dialect.

shevy-java 10mo ago

Yeah, I agree with this observation. Not sure why Rust is different here though.

morcus 10mo ago

I'm not a Rust evangelist, but I'm glad that Rust evangelists exist. I decided to try it for a medium-sized (~10k LoC) performance sensitive component recently and it has been an absolute joy to use.

mring33621 10mo ago
I'm mostly a Java dev, but baby-stepping Rust has been a lot of fun and reminds me, in a very good way, of the feeling I had in the late 90's when I was first learning Java.

benrutter 10mo ago

I think that's true - but I guess Rust and Zig are unique in that list on being new memory-managed languages (i.e. without garbage collectors). Low level memory-managed languages have been C and C++ mostly for a really long time, so I think Rust and Zig probably seem "more new" than the likes of Kotlin, Go, Elixir, Gleam, etc.

webnrrd2k 10mo ago

Yeah, Julia was all the rage for a while, and that kind of disappeared. Some languages, like elixir, stick around with a low-volume, but consistently positive mention on HN. Which makes me want to use it more.

stouset 10mo ago

Go has already more or less won its target market. Rust proponents are still working to convince C and C++ holdouts, who are understandably skeptical given the past several decades of promised replacements that never materialized.

gf000 10mo ago

Rust is absolutely novel in being the first, production-grade memory-safe low-level language.

array_key_first 10mo ago

Well that's because C, and C++, are uniquely awful and Rust can actually take them on. Kotlin doesn't have a strong case for replacing java because java is, well, just fine. At least it's safe. Sure it's, like, slightly inconvenient sometimes. And other languages like Go which originally claimed to take on C and C++ just don't. Go is garbage collected, it's not a real competition. But Rust is different. It's actually safe, and it's actually a real competitor. There's basically zero reason to choose C other than "I know it" or "one of my library author's knows it". Which are both very good reason, but incidently have nothing to do with the language itself.

LexiMax 10mo ago

> I think it's more than just the normal amount for advocacy of a new language. More than C++? More than Java? More than Python?