15 ms·

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professiona

> Dev velocity, which was supposed to be the claim to fame of Python, improved dramatically with Rust. I don't doubt this in the least. I've been a professional Python developer for 15 years, and I can't believe Python ever had the reputation for "high dev velocity" beyond toy examples. In every real world code base I've worked in, Python has been a strict liability and the promise that you can "just rewrite the slow parts in C/C++/Numpy/etc" has never held (you very often spend at least as much time marshaling the data to the target language format than you gain by processing in the faster language and you have all of the maintainability problems of C/C++/Numpy). Python trades developer velocity for poor runtime performance. I don't think Rust is the paragon of high dev velocity languages either, but it seems to be more predictable. You don't have something that works as a prototype, but then you run into a bunch of performance problems (which virtually cannot be worked around) when you go to productionize, nor do you get all of the emergent quality and maintainability issues that come about from a dynamic type system (and last I checked, Python's optional static type system was still pretty alpha-grade). I strongly recommend avoiding Python for new projects. Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or correctness-is-paramount software. I'm sure there are other decent options as well (I've heard generally good things about TypeScript, but I'd be concerned about its performance even if it is better than Python).

benreesman 4y ago
I think Rust deserves a lot of credit for popularizing the notion of “constraints as power”, but excessive enthusiasm around it does seem to obscure the rich traditions of PLT that it has more than liberally borrowed from. There are more rungs on the ladder.
- Kinrany 4y ago
  "Constraints as power" describes the proposition of all statically typed languages. But the compilers of popular languages weren't smart enough to cover many common scenarios, forcing language designers to offer many unsafe escape hatches.
  - benreesman 4y ago
    It’s a very valuable thing to be able to separate the mental model one uses from the target machine language. I worry about the more ardent Rust enthusiasts because it seems popular in those circles to embrace an attitude that we’ve somehow arrived at the right conceptual framework. Rust is a competent, pragmatic embedding of a few of the big ideas from serious PLT into a well-optimized C++ compiler toolchain, and it’s cool and useful as a result. But I hope to God it’s not the endgame on fast ML/Haskell/Lisp.
    - tialaramex 4y ago
      I'd be disappointed if the best language people are writing software in when I retire (perhaps a decade or at most two in the future) is Rust. We can surely do better. But I'd be even more disappointed if the best language people are writing software in when I retire isn't even Rust.
    - ldng 4y ago
      To be successful a language still has to be approachable to most dev. I just hope you are not conflating PLT with Functional. Look what functionalist did to Scala... It had an interesting balance and they destroyed it.
  - pjmlp 4y ago
    Interestingly Object Pascal was my introduction to data type modelling for constraints, followed by Caml Light, Modula-3 and Ada. Naturally one can argue they weren't popular, with exception of Object Pascal.
- throwaway894345 4y ago
  I say this as someone who has had a lot of criticism for Rust: Rust definitely borrows a lot from other languages, but Rust deserves praise precisely because it curates the right features and composes them in the right way. There are way too many languages from the PLT space that add some neat type system innovation, but they fail on syntax or performance or tooling or etc. That's not particularly laudable IMO, but Rust has great tooling (cargo, rust-analyzer, rustfmt, rustup, etc), great performance, great safety, and a bunch of type system innovations (including its approach to memory management) which were probably picked from the PLT world. The individual features are neat, but Rust is much greater than the sum of those borrowed innovations. Choosing what features to use and which to omit is a much more valuable task than any individual innovation.
  - benreesman 4y ago
    Credit where credit is due: Rust has done a far better job than most of free-riding on Haskell’s type class system and clang’s optimizer, but rust-analyzer is a dumpster fire next to clangd, that’s not an example I’d use.
    - mustache_kimono 4y ago
      Um what? Maybe it's just that I don't understand what clangd provides that's so great, but rust-analyzer, despite a few hiccups I've had with it, seems completely amazing at what it does.
      - benreesman 4y ago
        Well we could start with the fact that it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890 https://github.com/rust-lang/vscode-rust/issues/890 (it’s always LLVM’s fault, I know). Or move right along to the insane configuration hacks that are mandatory if you want anything upmarket of VSCode (who doesn’t need a little practice with their Emacs Lisp), or the N^2 whatever that happens when you point it at bindgen output. What clangd does is work.
- pjmlp 4y ago
  Yeah, specially when people refer to stuff taken from ML as Rust "features".
FartyMcFarter 4y ago
If people only used Python as originally intended (as a language to write small scripts in), this kind of problem never would have happened.
- throwaway894345 4y ago
  Sure, but the Python community itself promoted the idea that Python was suitable for general application development and so on. And it probably was a really good option back in the day when people were using C, C++, Perl, and PHPv4. And I'm sure there are still some areas where it's a fine option (maybe heavy data science stuff?). But I would only use it as an absolutely final resort.
  - ekidd 4y ago
    Greenfield Python programs that had strict type checking from day 1 can be pretty reasonable, as long as you know you never plan to write heavy data-munging code. I often work on codebase that involves typed async Python plus a collection of Rust CLI tools that do most of the heavy lifting. And it's really not bad at all.
- pjmlp 4y ago
  The only use case that makes sense for Python.
golergka 4y ago
> I've heard generally good things about TypeScript, but I'd be concerned about its performance even if it is better than Python I wouldn't recommend Typescript for CPU-bound tasks, but for I/O-bound tasks with complicated business logic it's type system is on the order of magnitude better than Go, and makes you able to get really close to the "make invalid states of the system a type error" ideal of functional languages like Haskell, while still being a lot more approachable.
- nazka 4y ago
  Talking about Haskell and stuff. You what I want? Rescript to replace entirely Typescript. That will be so much better.
  - golergka 4y ago
    Personally, I love ML-family languages and would enjoy writing in Rescript more, indeed. But I write software not to enjoy the process, but to solve business needs. And using Rescript, Scheme or Haskell drastically limits the talent pool and rises the cost. Which, BTW, can be very good for some businesses, that would want to hire only the best programmers anyway and are ready to pay for it. But that's some, not all.
    - nazka 4y ago
      Yes I agree. Also if you know your business won't need a lot of dev, like stuff like Instagram where I think they were still at 60 engineers even after hitting 1B active users, it can also be a good thing to use a niche (but viable) language to attract some bright engineers and they will be thrilled to be able to have a job to use it. Now I don't have such startup (yet) so I can't do it :) I just wish ReScript would have gained traction and replaced Typescript. But who knows maybe it can still happen.
  - still_grokking 4y ago
    I would endorse that. TypeScripts's type-system soundness holes kill the fun with that language very quickly, imho. That was a really big disappointment for me. A "static" language that compiles fine and than crashes at runtime with complete WTF-bugs is not much better than a dynamic language. You just can't trust the compiler and need to double check every line of code anyway. So there is not much additional value in this kind of "type safety". I would prefer Rescript of Scala.js anytime to TypeScript. Got really disillusioned by TS.
the__alchemist 4y ago
I think Python shines as an interactive calculator, eg an iPython REPL. Calculations, plotting etc. Or for website backends since Django is very nice. Or scripting OS tasks like file manipulation etc. For full projects outside websites, Rust for almost every case.
- zozbot234 4y ago
  Funnily enough, a REPL environment is in the works for Rust: https://github.com/google/evcxr https://github.com/google/evcxr
- lowbloodsugar 4y ago
  I like Octave (gnu matlab) for that.
- throwaway894345 4y ago
  I could get down with that, although my experience with the Python REPLs has been a mixed bag. Specifically, you can't easily deal with async stuff IIRC (not sure if that's been fixed or not).
Jack_rando_fang 4y ago
Agreed. I still give Python credit for allowing us to write software in an extremely efficient way. But after I wrote the initial version of the software with Python, I always procrastinate on testing, fixing existing issues, and as the software grows larger I simply want to give up as the different issues keep piling up. In comparison, Rust code usually just works out of the box due to the error handling and type system designs. With rust I develop much more consistently, and even more efficiently as the project progresses due to IDE hints, rust's built in `cargo check`, `cargo clippy` commands etc.
- nprateem 4y ago
  Don't you find thinking about the borrow checker unnecessary overhead while prototyping?
  - pdimitar 4y ago
    Of course. That's rarely debatable (unless making sure that you have a very small memory footprint is one of the project's critically important goals). The point is that you pay more upfront but can then iterate much more confidently and quickly.
  - jhgg 4y ago
    No. Not anymore. 4 years in and I maybe run into a borrow checker issue very rarely in a given week. Once you understand how the borrow checker works and how to write/structure your code in a way that the borrow checker is happy with it sort of becomes second nature. I think by side effect coding in this style does lend itself to simply writing better to understand code. Nowadays I just write my code this way without much thought. It happens effortlessly. I find myself writing programs in other languages like I would in Rust nowadays. This is compared to when I started and ran into borrow checking issues many times a day. Additionally the borrow checker has improved since then and NLL borrow checker will accept more programs as valid than the previous one.
    - nprateem 4y ago
      Interesting. I tried rust maybe 6 years ago and the combination of the BC and its slow compile times drove me away. Actually my main gripe was something to do with it not being obvious when calling a function that it needed a reference (I forget the specifics), but maybe that's been improved with better code completion in intellij. I may take another look.
cmrdporcupine 4y ago
Yes re: Python. Story -- I was a very early adopter of Python, back in the mid-90s. When other people wrote their CGI scripts in Perl, I always reached for Python. The first paid gig I ever had was a CGI script ("resume builder") I wrote in Python in 1996. But almost nobody was using it back then, and I'd get quizzical stares from people in job interviews etc. when it came up. So for many years back then I really really wanted to get a job working in Python. And I was super excited to get a job around the 2001 time frame in it on a pretty cool embedded Linux project. But my first experience working in a large codebase was disappointing. I could see right away that once many developers started working in that codebase together, best practices were really hard to enforce, and things started to fall apart into a bit of a mess, and lots of problems just showed up at runtime in bad explosions. That was the beginning of my disenchantment with dynamically typed, late-bound languages. They only give you the illusion of fast prototyping. You just shift your time to fixing type and binding errors later in your dev cycle. Python really improved a lot with the 2->3 transition, and the community has much better best practices now. But I think the core problem with late bound languages remains. All that said, I'm currently in another window working for my current employer wiring an embedded CPython interpreter into a Rust-based runtime...
- orangecat 4y ago
  I agree with most of this, but I would argue that the 2->3 transition was on balance a mistake. Python 3 is better, but not better enough to justify the huge amount of time and resources that otherwise could have been spent on better performance, typing, packaging, tools, etc. I'd gladly trade the Python 3 improvements for Python 2 equivalents of TypeScript and V8.
  - cmrdporcupine 4y ago
    You are probably right, I'm not invested in enough in that ecosystem to know one way or another. I do know lots of things remain disrupted by this transition in ways that still personally inconvenience me.
- DougN7 4y ago
  > They only give you the illusion of fast prototyping. You just shift your time to fixing type and binding errors later in your dev cycle. That is the perfect way to describe it! And sometimes you’re out of the dev cycle and into production if your test suite didn’t hit all cases.
hnfong 4y ago
I think this is a bit unfair. As always, blanket statements in software engineering aren't really meaningful. As I understand it, the article talks about switching from python to rust in a non-trivial database service that is required to be fast and robust. I can't imagine python to do well in this regard, especially when C/C++ extensions are required to enhance the performance. I also agree that 'Python has been a strict liability and the promise that you can "just rewrite the slow parts in C/C++/Numpy/etc" has never held'. I just don't agree those points necessarily imply "avoiding Python for new projects". Even in the case of the original article, was it, in hindsight, a bad decision to start with python? I'd argue not necessarily. Python is still great for quickly hacking together something that works, not necessarily fast or maintainable, but if you're under time pressure or you're still trying to feel out the market fit for your product, it's not a great idea to waste brain cycles to deal with borrow checks for example. Python's weaknesses only show when you need to scale, both on the performance and on the lines of code / number of collaborators metric, which is a problem you have only when the project succeeds. Avoiding python because of these problems reeks of premature optimization, unless you know it's how the project will end up in advance. As other sibling comments point out, python is still great for small scripts and weekend projects. Perhaps you do mean 'avoiding Python for new projects that are expected to grow non-trivially', which is fine advice. I'm just a bit tired of all those over-reaching blanket statements people make regarding software design that only really makes sense in a limited context (here's a funny one I've heard recently: never write nested-for-loops because it's sloooww). It would be unfortunate to have the message "don't use python for large projects" be misinterpreted as "python sucks no matter what".
- throwaway894345 4y ago
  > As I understand it, the article talks about switching from python to rust in a non-trivial database service that is required to be fast and robust. I can't imagine python to do well in this regard, especially when C/C++ extensions are required to enhance the performance. The article specifically talked about following the conventional Python advice to use C/C++ for the fast parts and Python for the "glue". This is precisely where Python people say Python shines. > I just don't agree those points necessarily imply "avoiding Python for new projects". You should avoid Python for new projects because you never know at the outset whether you will run into a performance bottleneck that can't be resolved by "just rewrite in C/numpy/etc" and there are other languages that are better than Python at both its strengths and weaknesses. The odds of painting yourself into a corner with Python are very, very high, and there are other languages that are better than Python at just about everything (the only area where Python still dominates is data science exploration libraries). Even if you don't paint yourself into a corner, you'll be dealing with lots of surprising papercuts: if you want reproducible builds, you'll have to wade through an ecosystem of package managers each with their own pitfalls including long build times (e.g., I saw pipenv take 30-45 minutes just to `pipenv lock` on a small-medium sized project); developing with docker basically doesn't work on mac (and windows?) because the VM uses all available CPU marshaling filesystem events over the guest/host boundary; your developers accidentally pulled in an API SDK that makes sync I/O calls (or else does some CPU-intensive task) which seizes up the event loop bringing the process down (and the failure cascades to remaining instances bringing the whole app down); and then there's the "regular" dynamic type system errors like forgetting to "await" things or missing/incorrect type documentation. > Even in the case of the original article, was it, in hindsight, a bad decision to start with python? I'd argue not necessarily. I'd argue not necessarily. Python is still great for quickly hacking together something that works, not necessarily fast or maintainable, but if you're under time pressure or you're still trying to feel out the market fit for your product, it's not a great idea to waste brain cycles to deal with borrow checks for example. My point isn't that Python is bad for literally every project--I actually think this project was probably a best-case scenario for Python (they didn't describe many of the issues I described in my previous paragraph) and they knew ahead of time where there performance issues would be so they were able to start with an architecture that was amenable to "write the slow parts in C/C++". My point is that there are languages that are better at fast iteration than Python (namely Go or TypeScript) while also excelling at Python's weaknesses (performance, tooling, distribution, type system, package management, etc etc etc). I think it's incredibly reckless to start a new commercial project in Python in almost all cases (with a possible exception for data science, but even then I would look hard at everything else first). > Python's weaknesses only show when you need to scale, both on the performance and on the lines of code / number of collaborators metric, which is a problem you have only when the project succeeds. This might be true for certain Django CRUD apps, but it's patently untrue in the general case. I've seen Python work fine for a prototype data science app, but fall over when real customer data was introduced. Similarly, I'm currently an SRE attached to a Python project which falls over regularly because of some event loop issue or another (often someone pulls in an SDK that makes sync calls under the hood, or else some CPU-intensive task blocks the event loop). I see stuff like this regularly, and it never happens in our Go apps. > As other sibling comments point out, python is still great for small scripts and weekend projects. Granted. Do what you want in your free time, but it's risky to use Python for new commercial apps. > Perhaps you do mean 'avoiding Python for new projects that are expected to grow non-trivially', which is fine advice. Yes, this is what I meant. I didn't mean "hobby projects". > I'm just a bit tired of all those over-reaching blanket statements people make regarding software design I don't usually make blanket statements, but Python really is so bad that this is a blanket statement I'm pretty comfortable with. I've scarcely ever heard of someone getting burned for picking Go over Python (there was some Python2 veteran who wrote an angry blog post once about Go back in the early days, but never since). Python just refuses to adequately progress because it wants to maintain compatibility--that's fine, but as professional engineers we should understand that the rest of the ecosystem is moving beyond where Python is willing/able to go, and it's no longer an appropriate tool for the overwhelming majority of new projects.
lijogdfljk 4y ago
> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or correctness-is-paramount software. I'd add one more addition to use Rust (speaking from an ex-Go dev): Use Rust if you want a robust std lib. Go is good, i used it for ~5 years, but man Rust was a breath of fresh air with the amount of tooling that helped me solve problems. Iterators, are a great example. I also preferred Crates vs Github Repos, but i think that's just personal preference.. not objective.
- skrtskrt 4y ago
  I think this comes with the caveat that there are a lot more mature libraries for Go just as a function of the age of the language.
  - lumost 4y ago
    Agree, you can see this in https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust vs. https://github.com/avelino/awesome-go https://github.com/avelino/awesome-go I've noticed however that there has been an uptick in great libraries over the last 2 years, with examples like pola.rs, rust-bert, tokenizers etc. starting to build momentum in the ecosystem.
  - pdimitar 4y ago
    That might have been true 2-3 years ago but nowadays whatever I can think of, Rust already has a library for it.
    - skrtskrt 4y ago
      Most recently I've run into Hyper not having tracing support
- johnisgood 4y ago
  When performance and correctness are paramount, I personally stick to Ada/SPARK. Proven to be perfect for the job, and to be honest, Rust is quite a difficult language and I am not sure it is worth learning it considering that Ada/SPARK ticks all boxes when it comes to both low-level and high-level programming for critical systems.
AtNightWeCode 4y ago
Docker is built with Go. Compare doing things with Docker api between Go and Python. I usually recommend people to "script" things with Go but I start to think that Go has to go... https://docs.docker.com/engine/api/sdk/examples/ https://docs.docker.com/engine/api/sdk/examples/
- metaltyphoon 4y ago
  Event the C# version is simpler :D https://github.com/dotnet/Docker.DotNet#example-create-a-container https://github.com/dotnet/Docker.DotNet#example-create-a-con...
- rkwasny 4y ago
  Exactly this, in rust it will even more complicated than in Go
- danwee 4y ago
  Wow. That's quite something. I like Go, but more often than not I keep stumbling upong these kind of situations (N LOC to do something in Y, 10xN to do it in Go).
  - reitanqild 4y ago
    In addition to a emulating certain teachers dogged insistence of making sure students can't have nice things (an absolute no-brainer feature like generics only showed up recently...!), last time I tried to use Go for a web project a few years ago I was also amused by the lack of templating libraries - the way to make pages was to string together header + main + footer, the old PHP way...! Not a single library supported template composition.
    - coder543 4y ago
      Umm... what are you even talking about? Go has had templating built into the standard library since... forever? And Go templates can use other templates, as long as they're all loaded into the same context, if that's what you were getting at. simple examples of Go's built-in templates: https://gowebexamples.com/templates/ https://gowebexamples.com/templates/ templates using other templates: https://levelup.gitconnected.com/using-go-templates-for-effective-web-development-f7df10b0e4a0#5a97 https://levelup.gitconnected.com/using-go-templates-for-effe...
zaphar 4y ago
Python has high dev velocity if you only measure how quickly you can get started on a project. The dev velocity drops exponentially with the size and complexity of your codebase. But it is indeed quite fast when you are just trying to get your first file of code written.
sitkack 4y ago
If Go replaces your Python this easily, you have always been writing Go. The abstractions available in Python are in a totally different class than that of Go. Nothing you said is verifiable.
- throwaway894345 4y ago
  > Nothing you said is verifiable. Right, I was pretty explicitly speaking from experience. See my first paragraph. > If Go replaces your Python this easily, you have always been writing Go Go is only a 10 year old language, and I've been writing Python professionally for 15 years. I definitely have more hours on Python by a wide margin. > The abstractions available in Python are in a totally different class than that of Go. Python definitely is more abstract than Go, but I don't think that's a feather in its hat. Moreover, most of my criticisms of Python had nothing to do with its abstract nature.
  - fwip 4y ago
    I think the intent of saying "you've always been writing Go" was along the lines of "you can write FORTRAN in any language." E.g, implying that you are not making use of Python's abstractions, but writing it in the same procedural style you would write Go (or C) code in.
    - throwaway894345 4y ago
      Fair enough, but that's still not the case. :)
    - sitkack 4y ago
      That is exactly what I am saying. I not talking trash about Go. But if one isn't using Python for what it is good at, don't use it, use the language you are actually using.
zmix 4y ago
> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Why not D?
- throwaway894345 4y ago
  I haven’t used it. As I mentioned, I’m sure there are other languages that fit the bill besides Go and TypeScript.
agumonkey 4y ago
Started a small project with rust and serde(toml config). Having static checking of config an its parsing felt really good.
- Gigachad 4y ago
  We started just writing configs in typescript which has the benefit of static checking in your editor with suggestions/underlines. Could likely do the same in rust.
  - agumonkey 4y ago
    I'm afraid by typescript "typesystem" even more so than rust borrows/lifetime. It's so versatile and stringy .. that said it's still good to have some.
    - Gigachad 4y ago
      What I'm proposing is rather than have Rust validate yaml/toml files, just write the actual config itself in Rust so that your editor can verify/show issues before running. Unless you require ability to edit configs without recompile.
lowbloodsugar 4y ago
I would recommend Rust even if writing a simple tool, the kind of thing I might previously have used python for. We had some data munging to do and someone started it in python. On the real dataset it ran for an hour then ran out of memory. I took a crack in rust, as a n00b rust programmer, and the rust version runs successfully in less than a minute. I haven’t tried server side yet, because the learning curve for that is more of a learning cliff, but for small things I am already faster in rust than with my decade of python.
- queuebert 4y ago
  Completely agree. Rust shines as a language for small tools that need to be performant and correct, like Unix utilities. Exa and fd are great examples of this.
- HeyImAlex 4y ago
  I had the same experience with go, 100x performance improvements on data crunching scripts with roughly the same code. Worst part of writing it in python was simple misspellings in the last stages of the computation breaking things.
  - vonseel 4y ago
    > Worst part of writing it in python was simple misspellings in the last stages of the computation breaking things. I'm not sure I understand. Was the typo in something like a dict key? Or did you add two of the wrong variables together? How did another language protect you from this? I fail to see how you couldn't also add two of the wrong variables (with the correct type) together in a different language.
    - HeyImAlex 4y ago
      Python (out of the box) will only complain about missing variables or methods at runtime.
- vonseel 4y ago
  >for small things I am already faster in rust than with my decade of python. That seems like a bold claim? I've also been writing Python for a decade and it takes no time at all to whip up a small script. I have no doubts the Rust version will be much faster, but stepping into a new language would take me at least longer to write the script than an equivalent version in Python. Plus there's all the other stuff to learn. Once you get past learning the basic syntax (creating variables, loop structure, assignment/etc.), you still have to pick up new things, like executing your work with parallelism, downloading files, parsing and dumping JSON, connecting to databases... Each new topic introduces a bunch of stuff that takes a little bit to figure out. I guess you could get through most of it in a few hours though if you had the right problem to work on. But still, there's the muscle memory aspect. Can a new language really sink in so fast that it's faster to use than Python after 10 years of writing Python?
salamanderman 4y ago
I've seen the transition from a Javascript codebase to a Typescript codebase with all strict checks in place to have a similar step change in dev velocity. The speed of debugging stupid mistakes, confidence in larger changes, and removal of a need for a lot of unit tests that were poor-person's type checking, is really significant. And runtime errors are a lot less weird than they were.
- mhink 4y ago
  > I've seen the transition from a Javascript codebase to a Typescript codebase with all strict checks in place to have a similar step change in dev velocity. The important factor here is "with all strict checks in place". Whenever I hear fellow FE devs complain about how they dislike Typescript, the complaints often seem to center around how it doesn't really offer that many guarantees... only to find out that their typechecker is set to the least strict settings! I'm not gonna lie, though: the transition from JS to TS absolutely comes with growing pains. This obviously includes actually updating the codebase and adding types, as well as the developer onboarding/learning process. Personally speaking, I found it very jarring to go from a permissive, lightning-fast JS dev cycle to a more methodical Typescript one. And don't get me started on how frustrating it can be to diagnose weird type errors related to generic types :D
queuebert 4y ago
Dev velocity in Rust is directly proportional to how well you grok lifetimes and ownership.
- throwaway894345 4y ago
  Eh, I like Rust and started my career doing embedded C and C++, so I definitely "grok lifetimes" but I'm probably always going to be more productive with Go than Rust (for general app development, anyway) if only because I don't have to think about memory at all with GC (again, general app development, not talking about performance optimizations). Even if I do a bunch of unnecessary cloning + Rc/etc in Rust, I'm not going to move as fast as I would do in Go.
deleted 4y ago
[deleted]
_benj 4y ago
Also, +1 for Go. I think that one of the things that makes Rust and Go such great language is how strict their compilers are. This moves the cognitive load of writing same code from the developer/team, to the compiler. Go is also simpler because of the GC, given that Rust can get a bit tricky with lifetimes. Go routines and channels are a delight to use together with contexts. Rust allows for a lot more ways to solve one problem, i.e. you can iterate over an array, of use a loop. Go only provided a for loop and that is pretty much the only way to iterate over something. Some people might find this limiting but I find it refreshing given that I can focus on what I need to do instead of how I should do it.
sharno 4y ago
I'd argue that C# (dotnet core) is a much better option than Go for an easy GC language with max productivity and great performance ceiling.
- metaltyphoon 4y ago
  Not only that, but greater tooling too.
- labrador 4y ago
  C# 2022 is much improved over earlier versions. For starts it's cross platform and compiles to reasonably sized single executables (touted as a strength of Go). Moreover, C# designers have started reducing boilerplate as much as possible, so for example, you don't need to declare a namespace, a class or a main to start coding. That said, Go is a fine language. It doesn't have exceptions last I checked, so that could be a deciding factor. Exceptions are handy in a lot of cases.
- throwaway894345 4y ago
  I haven't worked with C# since ~2013, but I mostly liked it. I'm sure it's a different beast now though. Some things I prefer about Go: 1. Tooling. `go build` just needs a `go.mod` file with a list of dependencies. There's no MSBUILD stuff (I think dotnet had a similar JSON file format, but then went back to MSBUILD?) 2. Runtime. I love that Go's default is static, native binaries, and that the ecosystem revolves around that. I especially love that this enables ~2mb Docker images. (I'm of the impression that you can do this in dotnet, but it's not clear to me how easy it is in practice or if there are performance tradeoffs) 3. Value types. Go doesn't have a classes; everything is a struct, and polymorphism and so on work on structs. 4. No inheritance. I'm pretty militantly opposed to inheritance. I know you don't have to use it in C#, but in Go I also don't have to deal with APIs or coworkers that assume inheritance. That said, these aren't major things; I'm sure C# is a great language in general, and I'd definitely reach for if I wanted to make a Windows GUI app.
  - CharlieDigital 4y ago
    1. `dotnet build` requires a .csproj file. It's XML based (they tried a JSON based format a few years back, but reverted to XML). C# and .NET's main strength, IMO, is the web API framework and general purpose utility; everything from web apps to Unity and Godot. It's easy to start with `dotnet new webapi -minimal` will give you a scaffolded project which is pretty similar a barebones Express or Flask app. But you get much more headway and scalability and the room to layer more complexity as needed. It's main detriment is, as you mentioned, the need for a somewhat heavy runtime and the relatively slow cold starts which make it a poor choice for things like CLI tools and serverless functions.
3pt14159 4y ago
I disagree. Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. Now you can say that this is a tradeoff for post Series B, and for that I don't know. I've never worked on a massive Python mono-repo for a company that size. But I know what I've done in Python and, yes, it includes performance optimization in Numpy / Scipy / Cython, and other than Ruby, no other language comes close to the developer performance I see with Python and the ecosystem around it. That said, there is a good and a bad way of writing Python. You absolutely need tests and lots of them since there is no compiler for vanilla Python. Mypy helps a ton too and so do the linters and even Black. Also, get pdb++ and customize it. The tooling helps a lot. Now I haven't ever written production Rust, but I have for Go and many other languages, and so Rust may be faster, but other than Ruby I haven't seen anything close.
- celdon25 4y ago
  > Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. Is there data on startup lifespan ranked by tech stack? Genuinely been looking for this for awhile now.
- badpun 4y ago
  > I disagree. > Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. It depends on what your goal is. If you want to get rich off of VC money, Python and Ruby might be a good fit. If you, on the other hand, want to write good, performant, maintenable and (relatively) bug-free software, then there are better choices.
  - manfre 4y ago
    Dev teams that are unable or willing to properly architect and test their projects will end up with buggy and difficult to maintainable code regardless of language.
    - eatonphil 4y ago
      That is unrelated to what the person you're responding to said.
peterkelly 4y ago
A lot of people seem to believe that dynamically typed languages make development easier, because you don't have to worry about writing type annotations or going through the extra steps to fix compile-time errors. This is arguably true for small scripts, but for anything non-trivial I find that static typing means I can be more productive, because type errors are caught straight away (rather than potentially in production), and I can be much more confident in refactoring code because I know certain kinds of errors will be caught by during type checking. This doesn't remove the need for automated testing, but does reduce the number of test cases you have to write. Things have improved a lot in the Python ecosystem of late with the introduction of type annotations and mypy, so to the extent possible I treat Python as if it's a statically typed language, putting type annotations everywhere and always making sure the codebase passes type checking before pushing a commit. However, the fact that this is optional sadly means that not everyone does it, and if you're working with parts of a codebase written without this level of discipline, you're basically back to square one. I've come to the conclusion that for medium to large projects, dynamic typing encourages sloppy programming, because it doesn't force people to think as carefully about what exactly their data types are, and whether they're being used correctly.
- tlrobinson 4y ago
  > I find that static typing means I can be more productive, because type errors are caught straight away I agree completely. I feel like there’s a pretty common arc among programmers: 1. learn to program using verbose statically typed languages 2. discover fun dynamically typed languages, eschew statically typed languages 3. discover dynamically typed languages are a shitshow for large real-world projects 4. re-discover fun/less verbose statically typed languages that make working on large projects tolerable
  - amelius 4y ago
    Except keep in mind that Rust adds more constraints than your typical statically typed language. It is still more fun and efficient to program in a language that is garbage collected and statically typed.
  - 4y ago
nurettin 4y ago
Python is fine, use the typing module, don't be weird with the return types and you will be fine. Sure, you will actually have to think about your algorithm when writing for speed, and naive loops won't work most of the time. But "avoid python in production" or "don't write new code in python" is way too harsh.
rjh29 4y ago
Having recently used it, my impression is Python's type system is pretty damn powerful. It might not be as crazy as TypeScript, but it can handle recursive types, dictionaries with a fixed set of keys, functions, union types and generics. Types can be re-used or exported. There are generic types for things like 'Iterable'. If a package does not supply its own types (increasingly rare now), you can generate stubs and put them in typings/$package. It's picked up a bunch of bugs for me already. And if runtime performance is not a priority, I'd rather write Python than Go or Rust any day. It's more fun and more expressive.
- rowanG077 4y ago
  Does it support annotating numpy arrays with their dimensions yet? Last time I checked I was incredibly surprised the status quo was basically all numpy arrays are np.ndarray.
  - rjh29 4y ago
    I think so: https://numpy.org/devdocs/reference/typing.html https://numpy.org/devdocs/reference/typing.html Which is cool, even strongly typed languages don't usually support that.
    - rowanG077 4y ago
      There is no example there that show that. I mean something like np.ndarray[1024, 1024, 1024, type=Int] which would mean a 3D array where each dimensions has 1024 elements. Basically all statically typed language support it. Even in C you can do it.
keyle 4y ago
I said this for years... no type checking by the compiler? Then you are the compiler.
deleted 4y ago
[deleted]
gmadsen 4y ago
python i think is still good prototyping. I can do numerical work, visualisations, animations, game dev, web dev, etc. for me python is just the biggest collection of tools while not being the best at anything. which is an ok trade off a lot of the times
deleted 4y ago
[deleted]

benreesman 4y ago

I think Rust deserves a lot of credit for popularizing the notion of “constraints as power”, but excessive enthusiasm around it does seem to obscure the rich traditions of PLT that it has more than liberally borrowed from. There are more rungs on the ladder.

Kinrany 4y ago
"Constraints as power" describes the proposition of all statically typed languages. But the compilers of popular languages weren't smart enough to cover many common scenarios, forcing language designers to offer many unsafe escape hatches.
- benreesman 4y ago
  It’s a very valuable thing to be able to separate the mental model one uses from the target machine language. I worry about the more ardent Rust enthusiasts because it seems popular in those circles to embrace an attitude that we’ve somehow arrived at the right conceptual framework. Rust is a competent, pragmatic embedding of a few of the big ideas from serious PLT into a well-optimized C++ compiler toolchain, and it’s cool and useful as a result. But I hope to God it’s not the endgame on fast ML/Haskell/Lisp.
  - tialaramex 4y ago
    I'd be disappointed if the best language people are writing software in when I retire (perhaps a decade or at most two in the future) is Rust. We can surely do better. But I'd be even more disappointed if the best language people are writing software in when I retire isn't even Rust.
  - ldng 4y ago
    To be successful a language still has to be approachable to most dev. I just hope you are not conflating PLT with Functional. Look what functionalist did to Scala... It had an interesting balance and they destroyed it.
- pjmlp 4y ago
  Interestingly Object Pascal was my introduction to data type modelling for constraints, followed by Caml Light, Modula-3 and Ada. Naturally one can argue they weren't popular, with exception of Object Pascal.
throwaway894345 4y ago
I say this as someone who has had a lot of criticism for Rust: Rust definitely borrows a lot from other languages, but Rust deserves praise precisely because it curates the right features and composes them in the right way. There are way too many languages from the PLT space that add some neat type system innovation, but they fail on syntax or performance or tooling or etc. That's not particularly laudable IMO, but Rust has great tooling (cargo, rust-analyzer, rustfmt, rustup, etc), great performance, great safety, and a bunch of type system innovations (including its approach to memory management) which were probably picked from the PLT world. The individual features are neat, but Rust is much greater than the sum of those borrowed innovations. Choosing what features to use and which to omit is a much more valuable task than any individual innovation.
- benreesman 4y ago
  Credit where credit is due: Rust has done a far better job than most of free-riding on Haskell’s type class system and clang’s optimizer, but rust-analyzer is a dumpster fire next to clangd, that’s not an example I’d use.
  - mustache_kimono 4y ago
    Um what? Maybe it's just that I don't understand what clangd provides that's so great, but rust-analyzer, despite a few hiccups I've had with it, seems completely amazing at what it does.
    - benreesman 4y ago
      Well we could start with the fact that it crashes process IDs more often than Justin Bieber crashes Maseratis: https://github.com/rust-lang/vscode-rust/issues/890 https://github.com/rust-lang/vscode-rust/issues/890 (it’s always LLVM’s fault, I know). Or move right along to the insane configuration hacks that are mandatory if you want anything upmarket of VSCode (who doesn’t need a little practice with their Emacs Lisp), or the N^2 whatever that happens when you point it at bindgen output. What clangd does is work.
pjmlp 4y ago
Yeah, specially when people refer to stuff taken from ML as Rust "features".

FartyMcFarter 4y ago

If people only used Python as originally intended (as a language to write small scripts in), this kind of problem never would have happened.

throwaway894345 4y ago
Sure, but the Python community itself promoted the idea that Python was suitable for general application development and so on. And it probably was a really good option back in the day when people were using C, C++, Perl, and PHPv4. And I'm sure there are still some areas where it's a fine option (maybe heavy data science stuff?). But I would only use it as an absolutely final resort.
- ekidd 4y ago
  Greenfield Python programs that had strict type checking from day 1 can be pretty reasonable, as long as you know you never plan to write heavy data-munging code. I often work on codebase that involves typed async Python plus a collection of Rust CLI tools that do most of the heavy lifting. And it's really not bad at all.
pjmlp 4y ago
The only use case that makes sense for Python.

golergka 4y ago

> I've heard generally good things about TypeScript, but I'd be concerned about its performance even if it is better than Python I wouldn't recommend Typescript for CPU-bound tasks, but for I/O-bound tasks with complicated business logic it's type system is on the order of magnitude better than Go, and makes you able to get really close to the "make invalid states of the system a type error" ideal of functional languages like Haskell, while still being a lot more approachable.

nazka 4y ago
Talking about Haskell and stuff. You what I want? Rescript to replace entirely Typescript. That will be so much better.
- golergka 4y ago
  Personally, I love ML-family languages and would enjoy writing in Rescript more, indeed. But I write software not to enjoy the process, but to solve business needs. And using Rescript, Scheme or Haskell drastically limits the talent pool and rises the cost. Which, BTW, can be very good for some businesses, that would want to hire only the best programmers anyway and are ready to pay for it. But that's some, not all.
  - nazka 4y ago
    Yes I agree. Also if you know your business won't need a lot of dev, like stuff like Instagram where I think they were still at 60 engineers even after hitting 1B active users, it can also be a good thing to use a niche (but viable) language to attract some bright engineers and they will be thrilled to be able to have a job to use it. Now I don't have such startup (yet) so I can't do it :) I just wish ReScript would have gained traction and replaced Typescript. But who knows maybe it can still happen.
- still_grokking 4y ago
  I would endorse that. TypeScripts's type-system soundness holes kill the fun with that language very quickly, imho. That was a really big disappointment for me. A "static" language that compiles fine and than crashes at runtime with complete WTF-bugs is not much better than a dynamic language. You just can't trust the compiler and need to double check every line of code anyway. So there is not much additional value in this kind of "type safety". I would prefer Rescript of Scala.js anytime to TypeScript. Got really disillusioned by TS.

the__alchemist 4y ago

I think Python shines as an interactive calculator, eg an iPython REPL. Calculations, plotting etc. Or for website backends since Django is very nice. Or scripting OS tasks like file manipulation etc. For full projects outside websites, Rust for almost every case.

zozbot234 4y ago
Funnily enough, a REPL environment is in the works for Rust: https://github.com/google/evcxr https://github.com/google/evcxr
lowbloodsugar 4y ago
I like Octave (gnu matlab) for that.
throwaway894345 4y ago
I could get down with that, although my experience with the Python REPLs has been a mixed bag. Specifically, you can't easily deal with async stuff IIRC (not sure if that's been fixed or not).

Jack_rando_fang 4y ago

Agreed. I still give Python credit for allowing us to write software in an extremely efficient way. But after I wrote the initial version of the software with Python, I always procrastinate on testing, fixing existing issues, and as the software grows larger I simply want to give up as the different issues keep piling up. In comparison, Rust code usually just works out of the box due to the error handling and type system designs. With rust I develop much more consistently, and even more efficiently as the project progresses due to IDE hints, rust's built in `cargo check`, `cargo clippy` commands etc.

nprateem 4y ago
Don't you find thinking about the borrow checker unnecessary overhead while prototyping?
- pdimitar 4y ago
  Of course. That's rarely debatable (unless making sure that you have a very small memory footprint is one of the project's critically important goals). The point is that you pay more upfront but can then iterate much more confidently and quickly.
- jhgg 4y ago
  No. Not anymore. 4 years in and I maybe run into a borrow checker issue very rarely in a given week. Once you understand how the borrow checker works and how to write/structure your code in a way that the borrow checker is happy with it sort of becomes second nature. I think by side effect coding in this style does lend itself to simply writing better to understand code. Nowadays I just write my code this way without much thought. It happens effortlessly. I find myself writing programs in other languages like I would in Rust nowadays. This is compared to when I started and ran into borrow checking issues many times a day. Additionally the borrow checker has improved since then and NLL borrow checker will accept more programs as valid than the previous one.
  - nprateem 4y ago
    Interesting. I tried rust maybe 6 years ago and the combination of the BC and its slow compile times drove me away. Actually my main gripe was something to do with it not being obvious when calling a function that it needed a reference (I forget the specifics), but maybe that's been improved with better code completion in intellij. I may take another look.

cmrdporcupine 4y ago

Yes re: Python. Story -- I was a very early adopter of Python, back in the mid-90s. When other people wrote their CGI scripts in Perl, I always reached for Python. The first paid gig I ever had was a CGI script ("resume builder") I wrote in Python in 1996. But almost nobody was using it back then, and I'd get quizzical stares from people in job interviews etc. when it came up. So for many years back then I really really wanted to get a job working in Python. And I was super excited to get a job around the 2001 time frame in it on a pretty cool embedded Linux project. But my first experience working in a large codebase was disappointing. I could see right away that once many developers started working in that codebase together, best practices were really hard to enforce, and things started to fall apart into a bit of a mess, and lots of problems just showed up at runtime in bad explosions. That was the beginning of my disenchantment with dynamically typed, late-bound languages. They only give you the illusion of fast prototyping. You just shift your time to fixing type and binding errors later in your dev cycle. Python really improved a lot with the 2->3 transition, and the community has much better best practices now. But I think the core problem with late bound languages remains. All that said, I'm currently in another window working for my current employer wiring an embedded CPython interpreter into a Rust-based runtime...

orangecat 4y ago
I agree with most of this, but I would argue that the 2->3 transition was on balance a mistake. Python 3 is better, but not better enough to justify the huge amount of time and resources that otherwise could have been spent on better performance, typing, packaging, tools, etc. I'd gladly trade the Python 3 improvements for Python 2 equivalents of TypeScript and V8.
- cmrdporcupine 4y ago
  You are probably right, I'm not invested in enough in that ecosystem to know one way or another. I do know lots of things remain disrupted by this transition in ways that still personally inconvenience me.
DougN7 4y ago
> They only give you the illusion of fast prototyping. You just shift your time to fixing type and binding errors later in your dev cycle. That is the perfect way to describe it! And sometimes you’re out of the dev cycle and into production if your test suite didn’t hit all cases.

hnfong 4y ago

I think this is a bit unfair. As always, blanket statements in software engineering aren't really meaningful. As I understand it, the article talks about switching from python to rust in a non-trivial database service that is required to be fast and robust. I can't imagine python to do well in this regard, especially when C/C++ extensions are required to enhance the performance. I also agree that 'Python has been a strict liability and the promise that you can "just rewrite the slow parts in C/C++/Numpy/etc" has never held'. I just don't agree those points necessarily imply "avoiding Python for new projects". Even in the case of the original article, was it, in hindsight, a bad decision to start with python? I'd argue not necessarily. Python is still great for quickly hacking together something that works, not necessarily fast or maintainable, but if you're under time pressure or you're still trying to feel out the market fit for your product, it's not a great idea to waste brain cycles to deal with borrow checks for example. Python's weaknesses only show when you need to scale, both on the performance and on the lines of code / number of collaborators metric, which is a problem you have only when the project succeeds. Avoiding python because of these problems reeks of premature optimization, unless you know it's how the project will end up in advance. As other sibling comments point out, python is still great for small scripts and weekend projects. Perhaps you do mean 'avoiding Python for new projects that are expected to grow non-trivially', which is fine advice. I'm just a bit tired of all those over-reaching blanket statements people make regarding software design that only really makes sense in a limited context (here's a funny one I've heard recently: never write nested-for-loops because it's sloooww). It would be unfortunate to have the message "don't use python for large projects" be misinterpreted as "python sucks no matter what".

throwaway894345 4y ago
> As I understand it, the article talks about switching from python to rust in a non-trivial database service that is required to be fast and robust. I can't imagine python to do well in this regard, especially when C/C++ extensions are required to enhance the performance. The article specifically talked about following the conventional Python advice to use C/C++ for the fast parts and Python for the "glue". This is precisely where Python people say Python shines. > I just don't agree those points necessarily imply "avoiding Python for new projects". You should avoid Python for new projects because you never know at the outset whether you will run into a performance bottleneck that can't be resolved by "just rewrite in C/numpy/etc" and there are other languages that are better than Python at both its strengths and weaknesses. The odds of painting yourself into a corner with Python are very, very high, and there are other languages that are better than Python at just about everything (the only area where Python still dominates is data science exploration libraries). Even if you don't paint yourself into a corner, you'll be dealing with lots of surprising papercuts: if you want reproducible builds, you'll have to wade through an ecosystem of package managers each with their own pitfalls including long build times (e.g., I saw pipenv take 30-45 minutes just to `pipenv lock` on a small-medium sized project); developing with docker basically doesn't work on mac (and windows?) because the VM uses all available CPU marshaling filesystem events over the guest/host boundary; your developers accidentally pulled in an API SDK that makes sync I/O calls (or else does some CPU-intensive task) which seizes up the event loop bringing the process down (and the failure cascades to remaining instances bringing the whole app down); and then there's the "regular" dynamic type system errors like forgetting to "await" things or missing/incorrect type documentation. > Even in the case of the original article, was it, in hindsight, a bad decision to start with python? I'd argue not necessarily. I'd argue not necessarily. Python is still great for quickly hacking together something that works, not necessarily fast or maintainable, but if you're under time pressure or you're still trying to feel out the market fit for your product, it's not a great idea to waste brain cycles to deal with borrow checks for example. My point isn't that Python is bad for literally every project--I actually think this project was probably a best-case scenario for Python (they didn't describe many of the issues I described in my previous paragraph) and they knew ahead of time where there performance issues would be so they were able to start with an architecture that was amenable to "write the slow parts in C/C++". My point is that there are languages that are better at fast iteration than Python (namely Go or TypeScript) while also excelling at Python's weaknesses (performance, tooling, distribution, type system, package management, etc etc etc). I think it's incredibly reckless to start a new commercial project in Python in almost all cases (with a possible exception for data science, but even then I would look hard at everything else first). > Python's weaknesses only show when you need to scale, both on the performance and on the lines of code / number of collaborators metric, which is a problem you have only when the project succeeds. This might be true for certain Django CRUD apps, but it's patently untrue in the general case. I've seen Python work fine for a prototype data science app, but fall over when real customer data was introduced. Similarly, I'm currently an SRE attached to a Python project which falls over regularly because of some event loop issue or another (often someone pulls in an SDK that makes sync calls under the hood, or else some CPU-intensive task blocks the event loop). I see stuff like this regularly, and it never happens in our Go apps. > As other sibling comments point out, python is still great for small scripts and weekend projects. Granted. Do what you want in your free time, but it's risky to use Python for new commercial apps. > Perhaps you do mean 'avoiding Python for new projects that are expected to grow non-trivially', which is fine advice. Yes, this is what I meant. I didn't mean "hobby projects". > I'm just a bit tired of all those over-reaching blanket statements people make regarding software design I don't usually make blanket statements, but Python really is so bad that this is a blanket statement I'm pretty comfortable with. I've scarcely ever heard of someone getting burned for picking Go over Python (there was some Python2 veteran who wrote an angry blog post once about Go back in the early days, but never since). Python just refuses to adequately progress because it wants to maintain compatibility--that's fine, but as professional engineers we should understand that the rest of the ecosystem is moving beyond where Python is willing/able to go, and it's no longer an appropriate tool for the overwhelming majority of new projects.

lijogdfljk 4y ago

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Use Rust if you're writing really high performance or correctness-is-paramount software. I'd add one more addition to use Rust (speaking from an ex-Go dev): Use Rust if you want a robust std lib. Go is good, i used it for ~5 years, but man Rust was a breath of fresh air with the amount of tooling that helped me solve problems. Iterators, are a great example. I also preferred Crates vs Github Repos, but i think that's just personal preference.. not objective.

skrtskrt 4y ago
I think this comes with the caveat that there are a lot more mature libraries for Go just as a function of the age of the language.
- lumost 4y ago
  Agree, you can see this in https://github.com/rust-unofficial/awesome-rust https://github.com/rust-unofficial/awesome-rust vs. https://github.com/avelino/awesome-go https://github.com/avelino/awesome-go I've noticed however that there has been an uptick in great libraries over the last 2 years, with examples like pola.rs, rust-bert, tokenizers etc. starting to build momentum in the ecosystem.
- pdimitar 4y ago
  That might have been true 2-3 years ago but nowadays whatever I can think of, Rust already has a library for it.
  - skrtskrt 4y ago
    Most recently I've run into Hyper not having tracing support
johnisgood 4y ago
When performance and correctness are paramount, I personally stick to Ada/SPARK. Proven to be perfect for the job, and to be honest, Rust is quite a difficult language and I am not sure it is worth learning it considering that Ada/SPARK ticks all boxes when it comes to both low-level and high-level programming for critical systems.

AtNightWeCode 4y ago

Docker is built with Go. Compare doing things with Docker api between Go and Python. I usually recommend people to "script" things with Go but I start to think that Go has to go... https://docs.docker.com/engine/api/sdk/examples/ https://docs.docker.com/engine/api/sdk/examples/

metaltyphoon 4y ago
Event the C# version is simpler :D https://github.com/dotnet/Docker.DotNet#example-create-a-container https://github.com/dotnet/Docker.DotNet#example-create-a-con...
rkwasny 4y ago
Exactly this, in rust it will even more complicated than in Go
danwee 4y ago
Wow. That's quite something. I like Go, but more often than not I keep stumbling upong these kind of situations (N LOC to do something in Y, 10xN to do it in Go).
- reitanqild 4y ago
  In addition to a emulating certain teachers dogged insistence of making sure students can't have nice things (an absolute no-brainer feature like generics only showed up recently...!), last time I tried to use Go for a web project a few years ago I was also amused by the lack of templating libraries - the way to make pages was to string together header + main + footer, the old PHP way...! Not a single library supported template composition.
  - coder543 4y ago
    Umm... what are you even talking about? Go has had templating built into the standard library since... forever? And Go templates can use other templates, as long as they're all loaded into the same context, if that's what you were getting at. simple examples of Go's built-in templates: https://gowebexamples.com/templates/ https://gowebexamples.com/templates/ templates using other templates: https://levelup.gitconnected.com/using-go-templates-for-effective-web-development-f7df10b0e4a0#5a97 https://levelup.gitconnected.com/using-go-templates-for-effe...

zaphar 4y ago

Python has high dev velocity if you only measure how quickly you can get started on a project. The dev velocity drops exponentially with the size and complexity of your codebase. But it is indeed quite fast when you are just trying to get your first file of code written.

sitkack 4y ago

If Go replaces your Python this easily, you have always been writing Go. The abstractions available in Python are in a totally different class than that of Go. Nothing you said is verifiable.

throwaway894345 4y ago
> Nothing you said is verifiable. Right, I was pretty explicitly speaking from experience. See my first paragraph. > If Go replaces your Python this easily, you have always been writing Go Go is only a 10 year old language, and I've been writing Python professionally for 15 years. I definitely have more hours on Python by a wide margin. > The abstractions available in Python are in a totally different class than that of Go. Python definitely is more abstract than Go, but I don't think that's a feather in its hat. Moreover, most of my criticisms of Python had nothing to do with its abstract nature.
- fwip 4y ago
  I think the intent of saying "you've always been writing Go" was along the lines of "you can write FORTRAN in any language." E.g, implying that you are not making use of Python's abstractions, but writing it in the same procedural style you would write Go (or C) code in.
  - throwaway894345 4y ago
    Fair enough, but that's still not the case. :)
  - sitkack 4y ago
    That is exactly what I am saying. I not talking trash about Go. But if one isn't using Python for what it is good at, don't use it, use the language you are actually using.

zmix 4y ago

> Use Go if you're looking for an easy GC language with max productivity and a decent performance ceiling. Why not D?

throwaway894345 4y ago
I haven’t used it. As I mentioned, I’m sure there are other languages that fit the bill besides Go and TypeScript.

agumonkey 4y ago

Started a small project with rust and serde(toml config). Having static checking of config an its parsing felt really good.

Gigachad 4y ago
We started just writing configs in typescript which has the benefit of static checking in your editor with suggestions/underlines. Could likely do the same in rust.
- agumonkey 4y ago
  I'm afraid by typescript "typesystem" even more so than rust borrows/lifetime. It's so versatile and stringy .. that said it's still good to have some.
  - Gigachad 4y ago
    What I'm proposing is rather than have Rust validate yaml/toml files, just write the actual config itself in Rust so that your editor can verify/show issues before running. Unless you require ability to edit configs without recompile.

lowbloodsugar 4y ago

I would recommend Rust even if writing a simple tool, the kind of thing I might previously have used python for. We had some data munging to do and someone started it in python. On the real dataset it ran for an hour then ran out of memory. I took a crack in rust, as a n00b rust programmer, and the rust version runs successfully in less than a minute. I haven’t tried server side yet, because the learning curve for that is more of a learning cliff, but for small things I am already faster in rust than with my decade of python.

queuebert 4y ago
Completely agree. Rust shines as a language for small tools that need to be performant and correct, like Unix utilities. Exa and fd are great examples of this.
HeyImAlex 4y ago
I had the same experience with go, 100x performance improvements on data crunching scripts with roughly the same code. Worst part of writing it in python was simple misspellings in the last stages of the computation breaking things.
- vonseel 4y ago
  > Worst part of writing it in python was simple misspellings in the last stages of the computation breaking things. I'm not sure I understand. Was the typo in something like a dict key? Or did you add two of the wrong variables together? How did another language protect you from this? I fail to see how you couldn't also add two of the wrong variables (with the correct type) together in a different language.
  - HeyImAlex 4y ago
    Python (out of the box) will only complain about missing variables or methods at runtime.
vonseel 4y ago
>for small things I am already faster in rust than with my decade of python. That seems like a bold claim? I've also been writing Python for a decade and it takes no time at all to whip up a small script. I have no doubts the Rust version will be much faster, but stepping into a new language would take me at least longer to write the script than an equivalent version in Python. Plus there's all the other stuff to learn. Once you get past learning the basic syntax (creating variables, loop structure, assignment/etc.), you still have to pick up new things, like executing your work with parallelism, downloading files, parsing and dumping JSON, connecting to databases... Each new topic introduces a bunch of stuff that takes a little bit to figure out. I guess you could get through most of it in a few hours though if you had the right problem to work on. But still, there's the muscle memory aspect. Can a new language really sink in so fast that it's faster to use than Python after 10 years of writing Python?

salamanderman 4y ago

I've seen the transition from a Javascript codebase to a Typescript codebase with all strict checks in place to have a similar step change in dev velocity. The speed of debugging stupid mistakes, confidence in larger changes, and removal of a need for a lot of unit tests that were poor-person's type checking, is really significant. And runtime errors are a lot less weird than they were.

mhink 4y ago
> I've seen the transition from a Javascript codebase to a Typescript codebase with all strict checks in place to have a similar step change in dev velocity. The important factor here is "with all strict checks in place". Whenever I hear fellow FE devs complain about how they dislike Typescript, the complaints often seem to center around how it doesn't really offer that many guarantees... only to find out that their typechecker is set to the least strict settings! I'm not gonna lie, though: the transition from JS to TS absolutely comes with growing pains. This obviously includes actually updating the codebase and adding types, as well as the developer onboarding/learning process. Personally speaking, I found it very jarring to go from a permissive, lightning-fast JS dev cycle to a more methodical Typescript one. And don't get me started on how frustrating it can be to diagnose weird type errors related to generic types :D

queuebert 4y ago

Dev velocity in Rust is directly proportional to how well you grok lifetimes and ownership.

throwaway894345 4y ago
Eh, I like Rust and started my career doing embedded C and C++, so I definitely "grok lifetimes" but I'm probably always going to be more productive with Go than Rust (for general app development, anyway) if only because I don't have to think about memory at all with GC (again, general app development, not talking about performance optimizations). Even if I do a bunch of unnecessary cloning + Rc/etc in Rust, I'm not going to move as fast as I would do in Go.

deleted 4y ago

[deleted]

_benj 4y ago

Also, +1 for Go. I think that one of the things that makes Rust and Go such great language is how strict their compilers are. This moves the cognitive load of writing same code from the developer/team, to the compiler. Go is also simpler because of the GC, given that Rust can get a bit tricky with lifetimes. Go routines and channels are a delight to use together with contexts. Rust allows for a lot more ways to solve one problem, i.e. you can iterate over an array, of use a loop. Go only provided a for loop and that is pretty much the only way to iterate over something. Some people might find this limiting but I find it refreshing given that I can focus on what I need to do instead of how I should do it.

sharno 4y ago

I'd argue that C# (dotnet core) is a much better option than Go for an easy GC language with max productivity and great performance ceiling.

metaltyphoon 4y ago
Not only that, but greater tooling too.
labrador 4y ago
C# 2022 is much improved over earlier versions. For starts it's cross platform and compiles to reasonably sized single executables (touted as a strength of Go). Moreover, C# designers have started reducing boilerplate as much as possible, so for example, you don't need to declare a namespace, a class or a main to start coding. That said, Go is a fine language. It doesn't have exceptions last I checked, so that could be a deciding factor. Exceptions are handy in a lot of cases.
throwaway894345 4y ago
I haven't worked with C# since ~2013, but I mostly liked it. I'm sure it's a different beast now though. Some things I prefer about Go: 1. Tooling. `go build` just needs a `go.mod` file with a list of dependencies. There's no MSBUILD stuff (I think dotnet had a similar JSON file format, but then went back to MSBUILD?) 2. Runtime. I love that Go's default is static, native binaries, and that the ecosystem revolves around that. I especially love that this enables ~2mb Docker images. (I'm of the impression that you can do this in dotnet, but it's not clear to me how easy it is in practice or if there are performance tradeoffs) 3. Value types. Go doesn't have a classes; everything is a struct, and polymorphism and so on work on structs. 4. No inheritance. I'm pretty militantly opposed to inheritance. I know you don't have to use it in C#, but in Go I also don't have to deal with APIs or coworkers that assume inheritance. That said, these aren't major things; I'm sure C# is a great language in general, and I'd definitely reach for if I wanted to make a Windows GUI app.
- CharlieDigital 4y ago
  1. `dotnet build` requires a .csproj file. It's XML based (they tried a JSON based format a few years back, but reverted to XML). C# and .NET's main strength, IMO, is the web API framework and general purpose utility; everything from web apps to Unity and Godot. It's easy to start with `dotnet new webapi -minimal` will give you a scaffolded project which is pretty similar a barebones Express or Flask app. But you get much more headway and scalability and the room to layer more complexity as needed. It's main detriment is, as you mentioned, the need for a somewhat heavy runtime and the relatively slow cold starts which make it a poor choice for things like CLI tools and serverless functions.

3pt14159 4y ago

I disagree. Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. Now you can say that this is a tradeoff for post Series B, and for that I don't know. I've never worked on a massive Python mono-repo for a company that size. But I know what I've done in Python and, yes, it includes performance optimization in Numpy / Scipy / Cython, and other than Ruby, no other language comes close to the developer performance I see with Python and the ecosystem around it. That said, there is a good and a bad way of writing Python. You absolutely need tests and lots of them since there is no compiler for vanilla Python. Mypy helps a ton too and so do the linters and even Black. Also, get pdb++ and customize it. The tooling helps a lot. Now I haven't ever written production Rust, but I have for Go and many other languages, and so Rust may be faster, but other than Ruby I haven't seen anything close.

celdon25 4y ago
> Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. Is there data on startup lifespan ranked by tech stack? Genuinely been looking for this for awhile now.
badpun 4y ago
> I disagree. > Most startups that YC has funded that became successful (Series B or higher) were written in Python or Ruby. It depends on what your goal is. If you want to get rich off of VC money, Python and Ruby might be a good fit. If you, on the other hand, want to write good, performant, maintenable and (relatively) bug-free software, then there are better choices.
- manfre 4y ago
  Dev teams that are unable or willing to properly architect and test their projects will end up with buggy and difficult to maintainable code regardless of language.
  - eatonphil 4y ago
    That is unrelated to what the person you're responding to said.

peterkelly 4y ago

A lot of people seem to believe that dynamically typed languages make development easier, because you don't have to worry about writing type annotations or going through the extra steps to fix compile-time errors. This is arguably true for small scripts, but for anything non-trivial I find that static typing means I can be more productive, because type errors are caught straight away (rather than potentially in production), and I can be much more confident in refactoring code because I know certain kinds of errors will be caught by during type checking. This doesn't remove the need for automated testing, but does reduce the number of test cases you have to write. Things have improved a lot in the Python ecosystem of late with the introduction of type annotations and mypy, so to the extent possible I treat Python as if it's a statically typed language, putting type annotations everywhere and always making sure the codebase passes type checking before pushing a commit. However, the fact that this is optional sadly means that not everyone does it, and if you're working with parts of a codebase written without this level of discipline, you're basically back to square one. I've come to the conclusion that for medium to large projects, dynamic typing encourages sloppy programming, because it doesn't force people to think as carefully about what exactly their data types are, and whether they're being used correctly.

tlrobinson 4y ago
> I find that static typing means I can be more productive, because type errors are caught straight away I agree completely. I feel like there’s a pretty common arc among programmers: 1. learn to program using verbose statically typed languages 2. discover fun dynamically typed languages, eschew statically typed languages 3. discover dynamically typed languages are a shitshow for large real-world projects 4. re-discover fun/less verbose statically typed languages that make working on large projects tolerable
- amelius 4y ago
  Except keep in mind that Rust adds more constraints than your typical statically typed language. It is still more fun and efficient to program in a language that is garbage collected and statically typed.
- 4y ago

nurettin 4y ago

Python is fine, use the typing module, don't be weird with the return types and you will be fine. Sure, you will actually have to think about your algorithm when writing for speed, and naive loops won't work most of the time. But "avoid python in production" or "don't write new code in python" is way too harsh.

rjh29 4y ago

Having recently used it, my impression is Python's type system is pretty damn powerful. It might not be as crazy as TypeScript, but it can handle recursive types, dictionaries with a fixed set of keys, functions, union types and generics. Types can be re-used or exported. There are generic types for things like 'Iterable'. If a package does not supply its own types (increasingly rare now), you can generate stubs and put them in typings/$package. It's picked up a bunch of bugs for me already. And if runtime performance is not a priority, I'd rather write Python than Go or Rust any day. It's more fun and more expressive.

rowanG077 4y ago
Does it support annotating numpy arrays with their dimensions yet? Last time I checked I was incredibly surprised the status quo was basically all numpy arrays are np.ndarray.
- rjh29 4y ago
  I think so: https://numpy.org/devdocs/reference/typing.html https://numpy.org/devdocs/reference/typing.html Which is cool, even strongly typed languages don't usually support that.
  - rowanG077 4y ago
    There is no example there that show that. I mean something like np.ndarray[1024, 1024, 1024, type=Int] which would mean a 3D array where each dimensions has 1024 elements. Basically all statically typed language support it. Even in C you can do it.

keyle 4y ago

I said this for years... no type checking by the compiler? Then you are the compiler.

deleted 4y ago

[deleted]

gmadsen 4y ago

python i think is still good prototyping. I can do numerical work, visualisations, animations, game dev, web dev, etc. for me python is just the biggest collection of tools while not being the best at anything. which is an ok trade off a lot of the times

deleted 4y ago

[deleted]