9 ms·

This is impressive. But IMHO, anyone starting today should just use Rust from the beginning, and avoid having to endure all of the problems for years and then t

by stmw 7y ago

This is impressive. But IMHO, anyone starting today should just use Rust from the beginning, and avoid having to endure all of the problems for years and then taking on a big HN-worthy post about 4M lines.

jdm2212 7y ago
Having never used Rust: how's the ecosystem around it like for maintaining it on production servers? Are there equivalents of Java Mission Control and `jcmd`?
- stmw 7y ago
  The ecosystem is good and growing, but not as extensive as java, of course. We use generic cloud monitoring/SRE tools (think statsd, not jcmd, for example). From prior experience, I also think JVMs somehow tend to require more of this kind of tooling, compared to Rust - or, for that matter, other languages & runtimes.
  - jdm2212 7y ago
    I'm curious how much Java needs the tooling in an all else equal situation (totally possible 'cuz Java is _old_) vs how much Java has all this cool tooling that enables/encourages people to do things that aren't possible in Go but which require the tooling. I've mostly used the Java, C++ and Go in my career, and it's pretty amazing to me that I can write write safe, readable code (like Go) on top of high-performance libraries (like C++) and step through code on a prod machine with a remote debugger, get live performance metrics with a single CLI command, etc.
- viraptor 7y ago
  Not in the same way. Since there's no significant runtime behind rust, there's no specific way to query it in an abstract way. On the other hand, native code means that you can use any common way to query the system. Anything you'd use for C or C++ will work as well. Profilers, stack querying, monitoring the process itself, user-level probes, etc. will work just fine. There's lots of tools that will work for this.
j88439h84 7y ago
If you're starting now, you could use typed Python on PyPy from the beginning.
- speedplane 7y ago
  > If you're starting now, you could use typed Python on PyPy from the beginning. And if you started 5 years ago, you're now likely spending half of your time over the next few months/years porting your code from Python 2 to 3. What a disaster.
  - StavrosK 7y ago
    In what world does it take years to port a Python 2 project to 3? This FUD gets tiring after a while.
vonseel 7y ago
Maybe if you're Dropbox, Rust is an option, but Rust is much, much more complicated than Python and not nearly as approachable - especially for beginners.
- ajxs 7y ago
  I'd argue that how complicated a language is shouldn't be a factor for a company at that scale. If it's the right tool for the job, and I'm not arguing that it is, then they have the ability to hire engineers capable of using it.
  - oscargrouch 7y ago
    I dont know the experience of others with this, but in reality is not that easy to have people with enough brain power or compromise for languages like C++ and Rust. Sure theres "enough for the world", if you sum everybody, but i bet that even a company of the size of Dropbox would have a hard time hiring everyone they need if the complexity of the language is the same as Rust or C++. For instance, if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. So the same way as Java before them, they created a language for the "average programmer". And you can see how the language is very pragmatic and how they fight to no put more complexity on the language. By the way, i know its a personal opinion, but i think Rust will not be a great fit for the cloud backend exactlya because of this kind of thing. It will be hard to create codebase as complex as the ones in Java, because there will be much less man-hours available. Maybe if generations are getting smarter, IDK, but needing to rely on a big head-count of C++ or Rust enginners for any company, i bet they will have a hard time to fill all the positions they need. Theres much more C++ enginners than Rust right now, and companies have a hard time hiring them (and i bet that for Rust it will be no different giving its complexity).
    - speedplane 7y ago
      > if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. My understanding was that the push from C++ to Go was largely motivated by long C++ compile/linking times. Go is designed to compile large code-bases much faster than C++. I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again.
bsder 7y ago
Uh, no. Rust crates are still full of the type of bugs that Python libraries killed years ago. Garbage collection overall really does make things easier. And Java still does concurrency better than practically everything else out there. If you are doing systems programming, go for Rust instead of C++. Maybe even Rust instead of C. But, I would reach for Python, Ruby, Kotlin, Clojure or even modern Java before Rust for most non-Javascript projects.
- j88439h84 7y ago
  I'm not familiar with Java's concurrency. In Python I'm excited about the idea of "structured concurrency", embraced by its wonderful Trio library. https://trio.readthedocs.io https://trio.readthedocs.io
  - bsder 7y ago
    java.util.concurrent is sheer utter brilliance condensed to code. If you're doing concurrency, you should look at how java.util.concurrent does it. And, then, if you aren't doing it that way, you should start asking really hard questions.
    - rixed 7y ago
      Such a strong wording lead me to check this library doc but I couldn't find anything in there unexpected or that looked particularly original, but only classical message queues, semaphores, futures and locks. Could it be that I looked at the wrong thing? Could you be more specific about what triggered such an enthusiastic description?
      - bsder 7y ago
        Reference here: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... Take a good look at things like ConcurrentLinkedDeque or ConcurrentSkipListSet and then look at what guarantees they do and do not make and think about the rationale behind those decisions. And all you have to do in java is create the collection, hand the reference to multiple threads, and IT JUST WORKS like a normal Java collection. You do NOT want to be using semaphores and locks directly if you have java.util.concurrent at your disposal. Look at the "Concurrent Collections" section: Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal: they may proceed concurrently with other operations they will never throw ConcurrentModificationException they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction. These are remarkably difficult properties to get correct. Then you have to think about fairness vs progress (the java.util.concurrent folks have thought about this a LOT). That library is something I sorely miss when I'm operating in another language. You should also dive into the code itself. Sometimes you'll look at a function and marvel at how much work it really takes to get something right. And sometimes you'll look at a function and wonder how it could possibly be so simple.
MoronInAHurry 7y ago
Why do so many people think "just rewrite it in Rust" makes sense to post on every single topic about a dynamic language, even though nobody ever does it because it doesn't actually work in reality?
- Pimpus 7y ago
  That's not what he said? You live up to your name though.

by stmw 7y ago

jdm2212 7y ago

Having never used Rust: how's the ecosystem around it like for maintaining it on production servers? Are there equivalents of Java Mission Control and `jcmd`?

stmw 7y ago
The ecosystem is good and growing, but not as extensive as java, of course. We use generic cloud monitoring/SRE tools (think statsd, not jcmd, for example). From prior experience, I also think JVMs somehow tend to require more of this kind of tooling, compared to Rust - or, for that matter, other languages & runtimes.
- jdm2212 7y ago
  I'm curious how much Java needs the tooling in an all else equal situation (totally possible 'cuz Java is _old_) vs how much Java has all this cool tooling that enables/encourages people to do things that aren't possible in Go but which require the tooling. I've mostly used the Java, C++ and Go in my career, and it's pretty amazing to me that I can write write safe, readable code (like Go) on top of high-performance libraries (like C++) and step through code on a prod machine with a remote debugger, get live performance metrics with a single CLI command, etc.
viraptor 7y ago
Not in the same way. Since there's no significant runtime behind rust, there's no specific way to query it in an abstract way. On the other hand, native code means that you can use any common way to query the system. Anything you'd use for C or C++ will work as well. Profilers, stack querying, monitoring the process itself, user-level probes, etc. will work just fine. There's lots of tools that will work for this.

j88439h84 7y ago

If you're starting now, you could use typed Python on PyPy from the beginning.

speedplane 7y ago
> If you're starting now, you could use typed Python on PyPy from the beginning. And if you started 5 years ago, you're now likely spending half of your time over the next few months/years porting your code from Python 2 to 3. What a disaster.
- StavrosK 7y ago
  In what world does it take years to port a Python 2 project to 3? This FUD gets tiring after a while.

vonseel 7y ago

Maybe if you're Dropbox, Rust is an option, but Rust is much, much more complicated than Python and not nearly as approachable - especially for beginners.

ajxs 7y ago
I'd argue that how complicated a language is shouldn't be a factor for a company at that scale. If it's the right tool for the job, and I'm not arguing that it is, then they have the ability to hire engineers capable of using it.
- oscargrouch 7y ago
  I dont know the experience of others with this, but in reality is not that easy to have people with enough brain power or compromise for languages like C++ and Rust. Sure theres "enough for the world", if you sum everybody, but i bet that even a company of the size of Dropbox would have a hard time hiring everyone they need if the complexity of the language is the same as Rust or C++. For instance, if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. So the same way as Java before them, they created a language for the "average programmer". And you can see how the language is very pragmatic and how they fight to no put more complexity on the language. By the way, i know its a personal opinion, but i think Rust will not be a great fit for the cloud backend exactlya because of this kind of thing. It will be hard to create codebase as complex as the ones in Java, because there will be much less man-hours available. Maybe if generations are getting smarter, IDK, but needing to rely on a big head-count of C++ or Rust enginners for any company, i bet they will have a hard time to fill all the positions they need. Theres much more C++ enginners than Rust right now, and companies have a hard time hiring them (and i bet that for Rust it will be no different giving its complexity).
  - speedplane 7y ago
    > if you read the Go manifesto to why the language was created, you can read between the lines that C++ getting in the way where enginners were fighting hard to deal with language complexity. My understanding was that the push from C++ to Go was largely motivated by long C++ compile/linking times. Go is designed to compile large code-bases much faster than C++. I've experienced this myself, it's pretty frustrating to wait 2-5 minutes for a C++ app to compile / link just so you can debug it for 30 seconds and start all over again.

bsder 7y ago

Uh, no. Rust crates are still full of the type of bugs that Python libraries killed years ago. Garbage collection overall really does make things easier. And Java still does concurrency better than practically everything else out there. If you are doing systems programming, go for Rust instead of C++. Maybe even Rust instead of C. But, I would reach for Python, Ruby, Kotlin, Clojure or even modern Java before Rust for most non-Javascript projects.

j88439h84 7y ago
I'm not familiar with Java's concurrency. In Python I'm excited about the idea of "structured concurrency", embraced by its wonderful Trio library. https://trio.readthedocs.io https://trio.readthedocs.io
- bsder 7y ago
  java.util.concurrent is sheer utter brilliance condensed to code. If you're doing concurrency, you should look at how java.util.concurrent does it. And, then, if you aren't doing it that way, you should start asking really hard questions.
  - rixed 7y ago
    Such a strong wording lead me to check this library doc but I couldn't find anything in there unexpected or that looked particularly original, but only classical message queues, semaphores, futures and locks. Could it be that I looked at the wrong thing? Could you be more specific about what triggered such an enthusiastic description?
    - bsder 7y ago
      Reference here: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... Take a good look at things like ConcurrentLinkedDeque or ConcurrentSkipListSet and then look at what guarantees they do and do not make and think about the rationale behind those decisions. And all you have to do in java is create the collection, hand the reference to multiple threads, and IT JUST WORKS like a normal Java collection. You do NOT want to be using semaphores and locks directly if you have java.util.concurrent at your disposal. Look at the "Concurrent Collections" section: Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators and Spliterators provide weakly consistent rather than fast-fail traversal: they may proceed concurrently with other operations they will never throw ConcurrentModificationException they are guaranteed to traverse elements as they existed upon construction exactly once, and may (but are not guaranteed to) reflect any modifications subsequent to construction. These are remarkably difficult properties to get correct. Then you have to think about fairness vs progress (the java.util.concurrent folks have thought about this a LOT). That library is something I sorely miss when I'm operating in another language. You should also dive into the code itself. Sometimes you'll look at a function and marvel at how much work it really takes to get something right. And sometimes you'll look at a function and wonder how it could possibly be so simple.

MoronInAHurry 7y ago

Why do so many people think "just rewrite it in Rust" makes sense to post on every single topic about a dynamic language, even though nobody ever does it because it doesn't actually work in reality?

Pimpus 7y ago
That's not what he said? You live up to your name though.