[HN Gopher] Why We Switched from Python to Go (2021)
___________________________________________________________________
Why We Switched from Python to Go (2021)
Author : hkallr
Score : 136 points
Date : 2022-05-26 08:27 UTC (14 hours ago)
(HTM) web link (softwareengineeringdaily.com)
(TXT) w3m dump (softwareengineeringdaily.com)
| radicalbyte wrote:
| I have experience with both (and a lot of other languages) and
| honestly - I wouldn't move from Python to Go. I'd move from
| Python to the very latest version of C#.
|
| You get far better tooling, excellent performance, the ability to
| write extremely concise code (as long as you don't apply
| mainstream coding standards/style) and a better range of
| libraries for most situations than Go. More chance for re-use too
| (i.e. same library for mobile apps, websites via web assembly,
| backend and apps for all major PC platforms).
|
| Also - the leaders of both Python and C# are coworkers - they
| both work at Microsoft.
| systemvoltage wrote:
| To me the biggest advantage Python has is the debugging
| capabilities. Especially combined with PyCharm, ad-hoc
| interpreter to check things while the execution is at a
| breakpoint - this is just like cheating. It is too good. I am
| not an expert software developer and haven't developed anything
| that needs to be fast, but for my needs, Python is really
| awesome.
|
| That said, I want to learn Go properly.
| hardware2win wrote:
| In c# you can edit code at fly when debugging, jumping
| between lines, evaluate expr and more like conditional
| breakpoints
| bloblaw wrote:
| Go debugging is nearly the exact same experience as Python.
| GoLand (from JetBrains ... same folks that make Pycharm) or
| VSCode with delve debugger work flawlessly.
|
| I don't think there is any difference between Go and Python
| when it comes to debugging. Support for both is widespread
| and high-quality.
| watersb wrote:
| > extremely concise code (as long as you don't apply mainstream
| coding standards/style)
|
| I'm interested in this aspect!
|
| I discovered that I was able to write short scripts in
| PowerShell in a style I find readable, or I can add extra stuff
| (parameter annotations, mostly, IIRC) and it can stretch to
| look like the C# I see in Microsoft API documentation. I find
| that the idea just gets buried.
|
| So I need to revisit C#, to find out how much can be
| effectively elided.
| radicalbyte wrote:
| The language has evolved greatly in the last few years. With
| LINQ and generics it was already nice but add on all the
| recent syntax sugar and ideas stolen from F#.. and you can
| write very nice code.
|
| Not all code will be though - we have a lot of Java-minded
| people in the community (who port Java libraries/frameworks)
| and they tend to be... ugly..
| metaltyphoon wrote:
| I have a feel that most people that use Go haven't had a chance
| to write code for the Government where its audited.
|
| Pulling third party packages would be instantly flagged and be
| put under high scrutiny.
|
| Meanwhile with C# and .NET's ungodly framework size you can
| just cruise along because it's made by the creators of the
| language.
| bsdnoob wrote:
| Go has a pretty decent standard library, you can go really
| far without adding a single third party library.
| prepend wrote:
| It's not much of an issue as long as you document your third
| party packages and versions.
|
| It's all going through an SA&A process that will check your
| c# framework as well as your random package downloaded from
| the interweb.
|
| (based on the decent amount of audited government work done
| using tons of third party libraries. Just try doing anything
| in data science without third party packages)
| christophilus wrote:
| I've worked extensively in C# (for the first 15 years of my
| career, it was my primary language), and built a handful of
| projects in Go. They're mostly comparable in terms of
| dependencies. The average C# project I was on-- in the last
| few years I worked in it-- had roughly the same number of
| Nuget dependencies as the Go projects I've seen.
|
| Both languages are great in this regard-- you can do a whole
| lot without 3rd parties.
| glintik wrote:
| Go vs Python comparision is really useless because of very
| different approaches and tools. Looks like "Why we switched from
| screwdriver to hammer".
| MengerSponge wrote:
| My team struggled with screwdriver for years before finally
| biting the bullet and switching to hammer. The first few days
| were tough, but after we learned the biggest pitfalls (hello
| bruised thumb gang) our productivity skyrocketed!
| ranjanprj wrote:
| I read somewhere on HackerNews that Python is kinda like a
| default language and rest such as Go, C, C++, Java are just for
| Optimization, once you figure out your solution.
| pjmlp wrote:
| On first startup we used Tcl, and C code for performance,
| similar to what is fashionable with Python nowadays.
|
| I had enough of the rewrite in C experience that since then, if
| the language doesn't come with a compiler on the box, either
| JIT or AOT, I only see it as scripting language for sysadmin
| work or learning purposes.
| mmcgaha wrote:
| AOLServer had a lot of defaults that would magnify the
| performance issues of TCL. The documentation did not cover
| all of the necessary configuration options to get a system to
| scale and you had to dig into driver.c to understand how to
| tune the system. I think the two big undocumented bottlenecks
| were maxsok and backlog. I bet if you were writing the same
| applications today, using modern hardware and Naviserver you
| would not have to write C modules anymore.
| pjmlp wrote:
| Our product was a competitor to AOLServer with CMS tooling
| for call centers.
|
| Also Vignette, remember it?
|
| When we dediced to move away from TCL/C, after exhausting
| the performance options, J2EE was going to be the next
| version.
|
| Due to a twist of fate of being Microsoft partners, we got
| invited to take part into .NET launch product line, and
| that Java rewrite became a .NET one instead.
|
| The original founders, after going through these
| experiences, went out and created OutSystems based on the
| learnings, naturally in .NET and later a Java backend was
| added as well.
| roflyear wrote:
| > I read somewhere on HackerNews that Python is kinda like a
| default language and rest such as Go, C, C++, Java are just for
| Optimization, once you figure out your solution.
|
| Python is extremely convenient when you are trying to be
| productive. It is a good general purpose tool, especially if
| you're doing anything web related. My project starts in seconds
| and requires no compilation. Stack traces and tooling for the
| language is far beyond most other popular languages IMO. The
| standard library is excellent, but also the quality of popular
| python libraries is unmatched by other languages in my
| experience.
|
| Python is not super fast at doing some stuff. If you're doing
| that stuff all the time it may not be a good choice. But for
| most of what I do, python is really good enough. A user will
| not notice a few 10s of Ms for that web request, and usually
| that isn't even the scale anyway for this type of stuff.
| [deleted]
| claytonjy wrote:
| I don't know who coined it but I love the term "second-best
| language for everything" when describing python. The ecosystem
| is so broad you can almost always find tools to do whatever you
| need, and it lets folks jump between domains simply by knowing
| the language.
| bloblaw wrote:
| Oh, that's a great way to put it. I'm stealing that :)
| d0mine wrote:
| What is the better alternative for being glue/executable
| pseudo-code?
| rbanffy wrote:
| Python is an excellent choice for that. What I tend to do is
| build with Python and, if (and that's a big if) the thing needs
| to be orders of magnitude faster, then we profile the app to
| find the hot spots and optimize those, either in Python, with
| some better approach, or in another language still being called
| from Python. A rewrite of a whole service from scratch is
| relatively rare in my experience (unless the original is really
| terrible and impossible to maintain).
| itsmemattchung wrote:
| I take a similar approach. Python allows me to rapidly
| prototype and ... gets the job done -- fast (in terms of
| developer productivity). Once performance becomes a main
| criteria, it's not so difficult to fork/exec some
| Go/Rust/C/C++ executable.
| rbanffy wrote:
| I'm thinking about using MPI for that - it should minimize
| the fork/exec time. Another approach is the extensive use
| of queues (which is a good thing anyway) and process the
| queue messages using a more optimized backend.
| IshKebab wrote:
| There's an element of truth to that in some cases, but it's
| mostly just something Python fans say to excuse the fact that
| Python is so slow.
|
| It's not true for two reasons:
|
| 1. In practice writing a prototype in one language, then
| completely scrapping it and rewriting it in another language
| almost never happens for fairly obvious reasons.
|
| 2. The "slow bits" of a Python program are rarely neatly
| concentrated in a few parts of the program that you can rewrite
| in a fast language. The _whole_ program is slow, so there 's no
| small part that you can rewrite to make it all faster.
|
| 3. There are other languages that are just as easy to use as
| Python (easier even!) but are also fast enough that you don't
| need to rewrite anything in most cases. Typescript is probably
| the best option at the moment but there's also Dart, Lua and
| probably others I've forgotten.
|
| Python is popular because it's seen as very beginner friendly
| so there's a mountain of content out there teaching people
| Python. Also the REPL makes it good for beginners and for
| science.
| d0mine wrote:
| The opposite is more plausible: it is rare when your
| performance issues are distributed evenly through the code.
|
| The very words such as bottleneck/hotspot indicate that it is
| common to get the most benefit by optimizing small parts of
| the code.
| digisign wrote:
| The point is you're very productive up front, and have a
| number of choices with the rest of your time. Few rewrite
| from the ground up because they don't need to.
| radicalbyte wrote:
| Python is the Visual Basic of 2022. Easy to understand, easy to
| learn and very forgiving. Much nicer than the main alternative
| (Javascript).
|
| Unskilled developers can be very productive very quickly.
| Skilled developers can write some really beautiful code with
| it.
|
| Has issues with the ecosystem - it's a headache with M1 and far
| too many Python projects are just broken. The latter is because
| it's used by scientists / students so is more a function of the
| community than the language.
|
| I use it as a scripting language, which it excels in as long as
| you don't have many dependencies.
|
| Go: fast and cgo is really powerful. The language itself is a
| little verbose for my tastes though - it makes the simple
| verbose. The package management story is weird (import the
| source code from github). Better than having the dependency
| hell of npm or Python though.
| caymanjim wrote:
| Python is a pretty terrible language to work with. Tooling
| sucks. Dependency conflicts are common. There's no test
| framework/runner worth a damn. Web frameworks are inferior to
| those in most other languages.
|
| If you're doing data science things, it's hard to beat
| pandas/numpy. I get that those are popular in that community
| because the barrier to entry with Python is low. People who are
| just looking for a tool to solve immediate problems would do
| well to reach for Python.
|
| The problems start when you try to write more complex things.
| Then you run into the weaknesses in tooling, testing, and
| performance. People would do well to skip Python and go right
| to another solution.
|
| I say this having spent half of the last decade working on
| Python projects. If not for data science and academia keeping
| it alive, it'd be disappearing along with Perl.
| digisign wrote:
| Sounds like inexperience or confusion, to be honest. None of
| those are problems particular to Python. Meanwhile you did
| not mention any of Python's significant issues, such as
| performance or deploying end-user apps. But it is best-in-
| class for what it was originally designed for.
| kortex wrote:
| > Python is a pretty terrible language to work with.
|
| _That 's just like, your opinion, man._
|
| > Tooling sucks.
|
| Not in my experience. Lot of tools could be better, but I
| would not say there is a lack of un-sucky tooling at this
| point. Poetry and pytest in particular are largely excellent
| to work with.
|
| > Dependency conflicts are common.
|
| This has been a problem historically but it's leagues better
| today, especially with lockfiles.
|
| > There's no test framework/runner worth a damn.
|
| Um, what? Unittest (stdlib), Pytest, tox, nose, hypothesis,
| schemathesis, and a few other lesser known ones.
|
| > Web frameworks are inferior to those in most other
| languages.
|
| FastAPI is pretty amazing. Flask is well regarded as a good
| intro framework. Django I'm not a fan of personally, but many
| love it.
|
| > If not for data science and academia keeping it alive, it'd
| be disappearing along with Perl.
|
| And machine learning. And web dev. And sysadmin scripting.
| ptx wrote:
| > _There 's no test framework/runner worth a damn._
|
| The built-in unittest module is essentially a clone of JUnit,
| so it can't be much worse, and most of the remaining
| limitations are fixed by pytest which people seem pretty
| happy with. What test frameworks are you comparing them to?
| systemvoltage wrote:
| > Dependency conflicts are common.
|
| Is it really?
| oliwarner wrote:
| > Web frameworks are inferior to those in most other
| languages.
|
| That's quite a statement. Go on, for most of the other
| languages, show me a web framework that's better than Django.
|
| Python absolutely has deployment challenges, but the
| performance is Good Enough(tm) and the speed of modelling and
| maintaining and accessing databases in Django's ORM is so
| much better than _anything_ else I 've found. Its Admin
| interface too is superb for same-day turnarounds on little
| CRUD projects. Nothing comes close.
|
| And I've written quite complex systems around Django. Ones
| that are multi-headed websites, APIs to physical hardware IO,
| ANPR, card readers, ID printers. Python hasn't let us down.
| shpongled wrote:
| I am a self admitted python- and ORM-hater and I agree.
| Django is pretty fantastic, and I have successfully used it
| to spin up several complete CRUD projects in a day or two
| bb88 wrote:
| If you use a DB, the DB will be the slowest aspect of a web
| framework, or any other kind of IO.
|
| 90% of the performance gains I've achieved are by
| optimizing/reducing large DB queries, or adding an index to
| the DB.
| claytonjy wrote:
| Of things you mention I feel the testing part the most. I
| started python recently enough that I've only ever used
| pytest, but something about it just feels too...magical? I'm
| holding out hope for a new test framework that I'd feel more
| at home with, but I'm not aware of any such projects; do they
| exist?
| ptx wrote:
| You could give the built-in unittest module [1] a try. It's
| less magical (although also less flexible) and many of its
| old limitations that people used to cite as advantages of
| pytest (e.g. built-in test discovery) have since been
| fixed.
|
| [1] https://docs.python.org/3/library/unittest.html
| gosukiwi wrote:
| I'm relatively new to Python, coming from Ruby and JS,
| and the built-in unittest module is just fine. I haven't
| had any issues with it, besides the documentation for
| setting it up following the conventions is really hard to
| find. But once it works, I like how simple it is. If you
| know OOP you'll feel right at home. You can simply create
| your own test case classes if you want to re-use stuff.
| No magical bloated configuration.
| d0mine wrote:
| If "too magical" is the only complaint that is mentioned,
| then pytest is not too bad :)
| wiz21c wrote:
| For the little data sciences like statistics and mildly
| complex ML, R is really good. At least for data exploration.
| The REPL/emacs combo I use is much better than
| python/jupyter. By better I mean it's far more productive to
| test ideas, compute statistics, charts, etc. Unfortunately R
| programs I write are not as structured as python programs. I
| wouldn't like to maintain that kind of code for a long time,
| nor would I build big applications in R.
| _fizz_buzz_ wrote:
| These are the kind of comments that really made me feel
| insecure when I started out to program. Every programming
| environment/language has its advantages and drawbacks and
| python is obviously not a terrible language. People build
| amazing stuff with python.
| llanowarelves wrote:
| You're right.
|
| The thing I want is a good monorepo solution for Python.
| There's at least 3 for JavaScript.
|
| As much hate as JS gets, its package managers are also much
| better than Pip.
|
| In order to manage complexity of Python as you do your big
| projects, you really need to do "enterprisey" patterns like
| DI. Even though it's rare for Python programmers to write
| like that.
|
| Re: test runner: pytest is pretty good
| jvolkman wrote:
| What are you looking for in a monorepo solution?
| 0x008 wrote:
| probably managing requirements.txt of sub-projects and
| virtual environment management?
| jvolkman wrote:
| This is possible with existing general monorepo tools. We
| use Bazel for Python and other languages. With Python, we
| have a single requirements.txt at the root of the
| monorepo, but each target (a Python package, a module, an
| app, or some combination thereof) depends only on the
| packages it needs and the transitive packages of its
| dependencies.
|
| Then if you need to do something like build a
| distributable archive for your app (say, to deploy it to
| lambda), you can use Bazel's dependency graph to get only
| the packages that the app transitively depends on.
| 0x008 wrote:
| What about the opposite case? I have several python
| packages with one requirements.txt each. But for
| development I want to have a single "root" virtual env?
| jvolkman wrote:
| In that case it seems like you could just have one
| all_requirements.txt that includes the individual files
| like: -r package_a/requirements.txt
| -r package_b/requirements.txt
|
| etc.
| 0x008 wrote:
| yes I get it. Good point.
|
| Is bazel also a good choice for managing the virtual
| environments of my developers? Do you have any examples?
| Gordonjcp wrote:
| > People would do well to skip Python and go right to another
| solution.
|
| Okay, so what solution? What do you recommend? I'm guessing
| if you're qualified to make statements like your first
| paragraph, you can bring your wealth of skill and experience
| to the table and show us what we should be using.
| digisign wrote:
| Yes, it has from the beginning been a fantastic prototyping
| tool, with a growing number of exit strategies for when you
| outgrow it. Or make do when you don't.
|
| It's had its deficiencies as well, exacerbated due to lack of
| investment, but that is changing. These are being knocked out
| one by one, every release.
| klodolph wrote:
| Python has problems scaling to medium-size code bases because
| programs above a certain size tend to become difficult to
| reason about. This is not a performance issue, and it's the #1
| issue that I choose to rewrite Python programs in other
| languages. Python type annotations help.
|
| IMO modern languages like Go and Java are pretty easy to get
| into and you can use them for a first implementation without
| really sacrificing development time relative to Python, as long
| as you have invested the time to learn those languages and the
| associated tools. (C++ is not like that unless you have made a
| very serious investment in setting it all up.)
|
| I'm not trying to say that any of these languages are
| better/worse, just that they are differently suited for
| particular situations (program size, team experience, etc)
| guitarbill wrote:
| > Python has problems scaling to medium-size code bases
| because programs above a certain size tend to become
| difficult to reason about. This is not a performance issue,
| and it's the #1 issue that I choose to rewrite Python
| programs in other languages. Python type annotations help.
|
| I think you're spot on. Is some ways, it is a tooling
| problem, as type annotations require mypy (or some other type
| checker), and enforcement via e.g. CI.
|
| Crucially, retrofitting them to a codebase is a difficult and
| tedious problem. On the other hand, it's relatively easy to
| do for new projects, but so is choosing a different language.
| erokar wrote:
| > Python has problems scaling to medium-size code bases
| because programs above a certain size tend to become
| difficult to reason about.
|
| In mye experience Python programs are not more difficult to
| reason about than equivalent Java programs. To the contrary
| an over-reliance on certain design patterns and ubiquitous,
| inescapable OOP complicates Java code bases, while the static
| typing is so weak it affords little safety compared to e.g.
| Python.
|
| Worth keeping in mind a that a Python program will be about
| half the LOC of a Java program doing the same thing. (See the
| reference section here [1].) In other words you can get
| further with Python before passing the complexity threshold.
|
| Bugs are also proportional to lines of code [2], which is
| another element that favours Python over more verbose
| languages like Java.
|
| 1. https://svese.dev/comparing-java-and-python-is-
| java-10x-more...
|
| 2. https://amartester.blogspot.com/2007/04/bugs-per-lines-of-
| co...
| usrn wrote:
| This probably really depends on who you're working with. I
| think Go is a lot better at forcing people to behave than
| Python is.
| gosukiwi wrote:
| Forcing people to behave is the opposite of Python's
| approach, afterall, [we are all consenting adults here](h
| ttps://mail.python.org/pipermail/tutor/2003-October/02593
| 2....)
| Spivak wrote:
| While this is something I very much appreciate about
| Python I think it's also true that structure needs to
| increase with the size of your codebase and the size of
| your team to avoid being driven mad. Python takes the
| "just apply discipline" approach which can absolutely
| work for lots of code but falls apart a bit with large
| heterogeneous teams.
| klodolph wrote:
| There's a speculation in the first citation:
|
| > Python is not maintanable above 50k to 100k lines of code
| and because of that people consider this code bases very
| large
|
| Note that this is a speculation, not a conclusion, the
| article is not very thorough, and LOC is mostly used
| because it is convenient to measure, not because it is what
| we are trying to measure. I'd personally consider 50k a
| "medium" code base, and 10k is "small".
|
| > Worth keeping in mind a that a Python program will be
| about half the LOC of a Java program doing the same thing.
|
| LOC is a confounding variable.
|
| > Bugs are also proportional to lines of code...
|
| Not supported by the citation. The citation measures bugs
| per line of code, and finds that for 500 kloc of code, the
| average number of bugs will be somewhere between zero and
| 25,000. That's a very wide range.
|
| To be clear, I'm not really trying to fight against Python
| or for Java here. I'm just giving my reasoning for why I
| might personally choose one or the other. I think that the
| idea that you would switch languages because Python is slow
| is actually far more situational. You might have ten
| reasons to choose Python or Java, runtime performance may
| only be one of those factors, it may not be heavily
| weighted, and in some cases, Python runtime performance can
| be extremely fast (I do a lot of NumPy stuff... it's
| great).
|
| The relationship between programming language and code
| quality is, at best, a difficult relationship to study.
| It's hard to make any kind of direct statement like "using
| language X results in more bugs than using language Y" and
| back it up by evidence, even though we believe it to be
| true. Individual statistics which relate some variable to
| LOC is not useful in isolation.
|
| See: https://arxiv.org/abs/1901.10220 (a reproduction of an
| earlier result, that invalidates many of the conclusions)
| lupire wrote:
| "Medium size codebase" means "bigger than a huge portion
| YouTube", which is in Python.
| Sohcahtoa82 wrote:
| > Python has problems scaling to medium-size code bases
| because programs above a certain size tend to become
| difficult to reason about.
|
| In my experience, this is because a lot of Python programmers
| are trying to write Java code in Python, carrying Java's
| awful and unreadable paradigms into a language that has no
| reason for them.
| RcouF1uZ4gsC wrote:
| > Python has problems scaling to medium-size code bases
| because programs above a certain size tend to become
| difficult to reason about.
|
| The other issue with Python is that it uses indentation for
| scoping. Combine that with the fact that it is super easy to
| mess up indentation when you are moving code around via
| copy/paste and it is super easy to change the meaning (ie
| accidentally move a statement out of an if block).
|
| Using indentation for scoping is great for small projects and
| for beginners. However, once you get to medium or large
| projects, having the extra redundancy of curly braces is
| reassuring.
| wing-_-nuts wrote:
| No. The lack of curly braces doesn't have a big impact on
| python being hard to reason about as the code base grows,
| it's the lack of tooling that comes with a strong
| statically typed language. It makes refactoring hard across
| a large code base.
|
| Python is a great scripting language, and it's a great
| language for hackers that work on their own personal
| projects. It's not a great language for enterprise
| microservices on teams of like 20 people. The growing pains
| are real.
| digisign wrote:
| Indentation has never been a problem with any of the code
| bases I've ever used. Ok, maybe there was that one script
| with tabs in it from ~2003?
|
| Not using a programming editor? I select the text and hit
| Tab or Shift+Tab, not exactly rocket surgery. The lack of
| redundant noise characters pays off every single day, where
| as odd indentation problems are a once-a-decade issue.
| Sohcahtoa82 wrote:
| Whenever someone complains about Python's indentation-as-
| syntax, my mind translates it as "this programmer writes
| terribly formatted code". If your code is properly
| formatted, then indentation will _never_ be a problem.
|
| Copy/pasting large blocks, yeah, you can mess it up. But
| any editor worth using will let you select several lines of
| text and hit Tab or Shift-Tab to add/remove an indentation
| level, so fixing it only takes a couple seconds.
| philwelch wrote:
| > But any editor worth using will let you select several
| lines of text and hit Tab or Shift-Tab to add/remove an
| indentation level
|
| ...or has equivalent functionality that doesn't require
| the mouse ;)
| gameswithgo wrote:
| [deleted]
| jasfi wrote:
| Nim is another option if you're wanting a language faster than
| Python, but with high productivity. The ecosystem is not quite
| there yet though. Nexus dev framework should help somewhat:
| https://nexusdev.tools
| was_a_dev wrote:
| THe ecosystem alone is putting me off comitting to Nim over
| Python. Although that attitude is a bit chicken and egg
| jasfi wrote:
| I'm nearly ready to commit the first code for Nexus. Your
| comment gave me extra motivation to get it done!
|
| I've actually written a lot of code and have used it for my
| own projects for some time, just need to get the release out
| now.
| fmakunbound wrote:
| > Why We Switched from Python to Go > Reason 5 - Fast Compile
| Time
|
| From Python??
| alephnan wrote:
| > Disadvantage 2 - Error Handling
|
| I'm by no means a Go expert, but it felt like Go forced
| consistent error handling.
|
| > Another issue is that it's easy to forget to handle an error by
| accident
|
| Does anyone have specific examples of error scenarios that skip
| through the cracks?
|
| > While this approach works, it's easy to lose scope of what went
| wrong to ensure you can provide a meaningful error to your users.
| The errors package solves this problem by allowing you to add
| context and a stack trace to your errors.
|
| Isn't this effectively just having propagating error Object that
| you stack context into ?
|
| On the one hand, I agree something like this should "be supported
| by the language" or rather forced especially since Go supposed to
| be opinionated, but on the other hand I appreciate having
| flexibility.
| foobiekr wrote:
| Error variable shadowing is a big one that occurs in go
| codebases. Along with the re-use of for loop variables, it is
| the most common Go footgun.
|
| The go language guys could fix both of these easily - force the
| caller to check error or explicitly drop it (_) optionally if
| non-null. That would almost completely eliminate the problem.
|
| I really like Go - I can pick up pretty much any Go code, from
| any open source project or any fellow engineer and read it with
| ease. No context, secret macros, implicits, etc. The code
| basically is what it appears to be. This is an enormous benefit
| in most contexts.
| kjksf wrote:
| There are lints for that, if that's really a big issue for
| you.
|
| I don't want that because I don't want to litter my code with
| `_ = fmt.Printf()`
|
| `Printf()` is a very common function. It returns an error. I
| don't care about an error from `Printf` and I don't want to
| make my code more ugly to avoid bugs I'm not writing in the
| first place.
|
| I've been writing Go code since before v1. I really can't
| recall a case where I wrote a bug because I forgot to handle
| an error.
|
| I get how you can forget something you do once a month.
|
| I don't get how you can forget to handle an error in Go when
| that's something you do every couple of lines of code
| written.
| foobiekr wrote:
| I regularly see both of the problems I mentioned when
| reviewing imported dependencies. Yes, the linters can help
| for your own code base, but something that forces
| correctness into all code is a big advantage over something
| that your dependencies may or may not bother with.
|
| Most people, I admit, do not review their dependencies, but
| that in and of itself is a problem.
|
| Your fmt.Printf issue is trivially addressed by
| implementing PrintfOrDrop() which wraps that - and if this
| was the way Go behaved, you can be certain the standard
| library would add these variants for conciseness.
| polskibus wrote:
| I'd love to read an objective comparison between Go and C#/NET6
| wrt to building services.
| metaltyphoon wrote:
| Its hard to see because most post won't try to use real world
| code.
|
| An objective comparison would need:
|
| * Authentication n Authorization
|
| * Rate limiting
|
| * Configuration loading
|
| * OAuth integration
|
| * Websockets
|
| * Retry policies
|
| * HTTPs (yes... all the way to uService)
|
| * Testing
|
| * Benchmarks
|
| * Cloud tooling (integration)
|
| * C interop
|
| * Service Caching
|
| * Middleware authoring
|
| And many more...
| Xeoncross wrote:
| I always wondered why Stream was using Python instead of Go. Glad
| to hear they are able to make the change now. There is no
| comparison between Go and my Python or Node.js services when it
| comes to data processing or pipelines.
|
| > Revel, Iris, Echo, Macaron and Buffalo seem to be the leading
| contenders.
|
| If you're talking about MVC-era frameworks these are fine.
| However a lot of companies are using Go for microservices so I
| would highly recommend looking at https://goa.design/ and
| https://gokit.io/
| eesmith wrote:
| > Glad to hear they are able to make the change now
|
| This was written 4 1/2 years ago.
| rascul wrote:
| It's dated Wednesday, March 3 2021. Is there another date I
| missed?
| eesmith wrote:
| https://news.ycombinator.com/item?id=31517109
| rascul wrote:
| I apparently didn't get far enough in the comments.
| Thanks for pointing that out. I didn't make the original
| comment you replied to, I had just noticed and was
| confused by 2021 not being 4 years ago.
| gentleman11 wrote:
| The post read like a sober description of some reasoning. The
| tech switch blogs we usually see are, by comparison, informal and
| feel somewhat half baked, where the author seems like their goal
| is to look like a cool leader of the valley. That's what stuck
| out to me about this personally, it was refreshing
| tschellenbach wrote:
| Author here, funny to see my old post. Any questions about how we
| use Go nowadays?
| istorical wrote:
| Have you become more fond of / optimistic about Go (compared to
| other options) since writing the piece, less so, or similar?
| OhHiMarkos wrote:
| Nice article. Curious about whether Go fits your needs and
| would it be your choice if you would change be choosing a new
| language nowadays.
| foobiekr wrote:
| slaymaker1907 wrote:
| I get frustrated with this nonsense that writing tons of
| boilerplate is somehow beneficial. As someone who actually reads
| a lot of code, no it isn't. I want to see the core logic, not an
| essay on how to iterate through an array. You can cut the
| bullshit code without resorting to cryptic Perl-like code.
|
| Adding in more bullshit just gives me more code I have to read
| that I may not actually be interested in while also spreading out
| the code of interest.
|
| In the horrific example code posted, all that should be there is
| the URL, that it is a GET, and parsing of JSON (maybe into
| struct). Or in other words, "fetch(url).then(resp =>
| resp.json())" with some validation code elsewhere, though in this
| case it's just one field so validation of the whole response is
| probably unnecessary.
| KaiserPro wrote:
| As with all of these posts, the big reason is never really
| written:
|
| "I just wanted to learn a new language"
|
| Now, the points they've made are valid, Go concurrency beats the
| pants off python, and with gofmt, there is less of a debate about
| style.
|
| Te bit about finding a team is pure horse cock. As they point out
| there are a bunch of C++/C programmers about. There are even more
| python programmers too. Go is a tiny pond compared to the big
| three (c, java, python).
| tasuki wrote:
| > As with all of these posts, the big reason is never really
| written:
|
| > "I just wanted to learn a new language"
|
| Strong disagree. If the actual purpose was learning new things,
| they'd have chosen a language which does things a little
| differently than all of the mainstream. At least Haskell or
| some Lisp...
|
| The fact they chose Go shows they care primarily about the
| practical side.
| BobbyJo wrote:
| > "I just wanted to learn a new language"
|
| and
|
| > finding a team
|
| Are connected. More people out there would be willing to work
| in Go than Python, even if more people know python. First, a
| large portion of python writers aren't backend devs, whereas
| pretty much all Go users are. Second, Python has a very bad rap
| as a backend language, and for pretty good reason. Third, if
| someone doesn't know Go, then can still get up to speed and use
| the language extremely proficiently within a few months, unlike
| any of the other languages you listed.
| KaiserPro wrote:
| > if someone doesn't know Go, then can still get up to speed
| and use the language extremely proficiently within a few
| months
|
| Which combined with a new code base is very stressful. but
| this avoids the main point, which is
|
| > Python has a very bad rap as a backend language,
|
| its not a front end language really(discounting the
| transpiled JS web stuff). I know people dont like it, and
| that's fair enough, but its as good as virtually any other
| language for "backend stuff". Its perfectly possible to write
| low latency high scaling code in python, just as it is in go
| and rust.
|
| Despite what people say, code is just a logic brush, how you
| hold it, and how toy paint with it determines how pretty the
| picture is.
|
| Yes there are inherent defects that each language has, but
| once again part of being proficient is know how not to blow
| your feet off. If Goethe can make wonderful prose in german,
| you too can make good scalable backend code in python.
| tbarbugli wrote:
| co-founder and CTO of Stream here. I did not write the article
| but I was very involved with the decision process.
|
| Your assumption is wrong, we did not pick a different language
| just for fun or because we wanted to learn something new :)
|
| Python was just not the language we needed for our APIs, we
| tried hard to make it work but eventually we looked at
| alternatives that would allow us to keep things simple and
| performant. End result was better latencies, a much simpler
| architecture (less async/MQ work) and processes that would eat
| a fraction of RAM and CPU compared to Python.
| throwaway894345 wrote:
| > Te bit about finding a team is pure horse cock. As they point
| out there are a bunch of C++/C programmers about. There are
| even more python programmers too. Go is a tiny pond compared to
| the big three (c, java, python).
|
| If you can program in any language, you can program in Go.
| There's so much less to learn than even Python (perhaps
| _especially_ Python when you consider all of the different
| packaging tools, testing frameworks, sync vs async, decorators,
| metaprogramming, etc).
| gkop wrote:
| For those of us not deeply familiar with Python vs Go, can you
| share a bit about why gofmt is so much better than the Python
| status quo (IE what's wrong with autopep8 mentioned in
| article?)?
| snorfalorpagus wrote:
| I don't think there is a status quo. There is choice between
| autopep8, yapf (which itself supports 4 different styles),
| black, and maybe some more I'm missing. With languages that
| have a built in formatter this isn't an issue.
| gkop wrote:
| What's the material consequence of this lack of uniformity?
| When a new Python developer joins a team, is it painful or
| costly to accommodate their stylistic preferences? I see a
| single standard as a nice to have, but as long as the
| language has adequate tooling with reasonable defaults and
| quality linting, this just doesn't seem like a big deal.
| Curious to learn first hand experience of those that
| switched from Python to Go...
| BobbyJo wrote:
| The biggest issue I've felt with Python formatting is you
| run into build/versioning issues that basically never
| happen with gofmt. Also, some tools don't do everything
| you need, and you need multiple, like having to combine
| isort and black.
| prepend wrote:
| I've found it's nice for detecting people who care about
| unimportant things.
|
| I can't imagine ever picking a language based on this
| feature and seems weird to even mention it.
|
| This has never caused me a minute of headache and the
| only time I care is when conflicting styles are used in
| the same file.
|
| I always thought it was kind of dumb of Go to care about
| this but don't care enough to affect my language choice.
| I don't use Go but am open if it's a fit for a project.
|
| I like that Python has that variability and let's
| developer make decisions as they see fit.
|
| I don't want to talk to people about tabs and spaces
| unless we're already friends and having a few beers.
| gkop wrote:
| In candor I dabbled in Go in 2016 and found the community
| leaders arrogant and rude. I hope the community has
| evolved since then to expect more from leaders, but would
| need to see evidence of this before touching Go
| voluntarily again.
| philwelch wrote:
| autopep8 isn't deterministic enough. If you were going to
| autoformat your Python you'd want to use Black, which has the
| same philosophy as gofmt.
| sliken wrote:
| Go has one, the same one used by the compiler, so there's no
| arguments, no multiple standards, etc. Python has a few
| options, and when a new language feature comes out the time
| to implementation may vary.
|
| Think of it this way, if you could all the python code on
| github and ran it though autopep8, what fraction of the files
| would be changed?
|
| Generally in the go community, contributions, patches, code,
| etc that's not formatted with gofmt is considered
| wrong/broken.
| mountainriver wrote:
| It's also an example of how Go thinks about all problems.
| Do things one way that is well made and roughly satisfies
| most use cases
| gkop wrote:
| Thanks! More curiosity:
|
| How do humans that disagree with the One Format deal with
| it? Do they self-select away from Go?
|
| > Think of it this way, if you could all the python code on
| github and ran it though autopep8, what fraction of the
| files would be changed?
|
| How does the format evolve over time as the community
| discovers improvements (if it does), and what are the
| implications for code on github?
| sliken wrote:
| Generally I think most agree that gofmt makes pretty good
| decisions and it's better to have one format than
| competing formats that make it ugly when someone joins
| the team, or you are importing a library. The more you
| read code the nicer it is to have it all in the same
| format.
|
| Like much of go, there's the "go" way to do it, and the
| language simplicity reduces the chance of multiple
| programmers taking multiple approaches that are all
| different enough to require wrappers to interoperate.
| Sure your pet feature from some other language may be
| missing.
|
| The language (and gofmt) have evolved. In particular
| since the parser is externally usable (by gofmt, IDEs,
| and other tools) you can actually use that tool to rename
| variables, functions, etc without having to worry about
| getting a REGEXP right. So when there's the occasional
| incompatible change gofmt can parse code into a tree,
| make a transformation, and then back info code ...
| including comments.
|
| It's relatively common (in my experience anyways) to have
| commit hooks in git run gofmt on go code. Generally go's
| been very compatible, none of the issues like Python2 vs
| Python3. I'm sure some avoid go for these reasons, but I
| lump them in with folks that reject python because of
| whitespace/indenting.
| returningfory2 wrote:
| The point of view in Go is that the specific format is
| irrelevant. The design choices made by the format don't
| matter. What you think is "nice" code and what someone
| else thinks is "nice" code doesn't matter. The benefit of
| formatting has nothing to do with making the code conform
| to anyone's definition of "nice". It's just about having
| a format that's passable and that is then applied
| uniformly.
| PeterisP wrote:
| If you disagree with the One Format, you can configure
| your IDE to show (or transform) the code in a different
| style while you're working with it, and have the One
| Format be the format for storage of the source.
| spapas82 wrote:
| Nowadays black is a defacto standard in python formatting.
| throwaway894345 wrote:
| Black is awesome for the Python ecosystem, but it's still
| painfully slow for large files compared to gofmt.
| Spivak wrote:
| How large is large because I don't think I've ever even
| noticed black's delay on 10k files.
| throwaway894345 wrote:
| It would pause for a few seconds on 1-3kloc files on a
| fully loaded 2019 macbook pro.
| tech_tuna wrote:
| You down with RDD?
| sgt wrote:
| Why We Switched Back to Python (2023)
| eesmith wrote:
| Something is odd about the timing.
|
| This article is dated "Wednesday, March 3 2021" but appears to be
| identical to https://getstream.io/blog/switched-python-go/ dated
| Oct 17, 2017 and updated either May 14th 2019 or Sep 15, 2020.
|
| Both say "Early this year, we switched Stream's primary
| programming language from Python to Go", and there was HN
| discussion about it on Oct 17, 2017 at
| https://news.ycombinator.com/item?id=15495562 (397 comments).
| tomComb wrote:
| The Internet is awash with fake dates - old material 'up-dated'
| to make it appear current - but I wouldn't expect that sort of
| thing from SED which I have a decent amount of respect for.
|
| Perhaps the author took something he had written before, and
| really did update it before republishing?
| tschellenbach wrote:
| Someone cross posted my content from 2017. It's been 4+ years.
| rowanajmarshall wrote:
| The author of the Software Engineering Daily post is credited
| as Thierry Schellenbach, CEO of Stream, so I'm guessing it's
| just a cross-post.
| eesmith wrote:
| Sure, but why do a cross-post years later without saying the
| information might be dated?
|
| For example, you cannot now "Swap out True and False". That
| was changed in Python 3, and while many were still using
| Python 2 in 2019, it wasn't so true in 2021.
|
| I also wonder how numba does with the
| "simple_gauss(time)*popularity" expression.
| gentleman11 wrote:
| It looks like this blog is republishing the older article. It's
| the authors only post on this site. His main blog seems to be
| medium maybe? The stream.io blog links I found didn't work so
| maybe they were originally posted there and are disorganized
| since then?
| treis wrote:
| Dead giveaway is that it links to the StackOverflow survey from
| 2017
| yedpodtrzitko wrote:
| So they switched to Go from Python, because of following
| advantages:
|
| #1 Performance
|
| #2 Performance (to make the list longer I guess?)
|
| #5 Fast compile time... which is an advantage over Python how
| exactly?
|
| #7 Strong ecosystem... which brings us to disadvantage #1 - lack
| of frameworks (?)
| snapetom wrote:
| I'm surprised they didn't mention #1 implies a cost benefit, or
| maybe they don't use it at scale in certain areas that it
| matters. I worked with one company that switched from Python to
| Go. They went from twenty-one instances of their load-balanced
| API servers to seven, saving a few thousand dollars every
| month.
| potta_coffee wrote:
| This is my favorite advantage of Go. It does the work faster
| with fewer resources. I know there are a lot of aesthetic
| complaints about the language but I don't care.
| todotask wrote:
| There is a new framework, still infancy, bud, which was
| recently shared on Reddit and you can watch the video:
|
| https://www.youtube.com/watch?v=LoypcRqn-xA
|
| Plenty of other frameworks which you have a specific framework
| is lacking in the Go ecosystem?
| Vanclief wrote:
| You really don't need frameworks on go. You go and pick
| whatever tools you need like ORMS, http routers or loggers.
|
| It is only a disadvantage if you want to have a framework.
| toolz wrote:
| you don't need frameworks in any language - the frameworks
| (for mature frameworks) are almost always modular enough that
| you can use the parts without the whole.
|
| I prefer frameworks the same way I prefer code linters and
| formatters. Which is to say they are annoying, but far less
| annoying than working with a team that spends obscene amounts
| of time discussing/rewriting code based on opinions.
| Frameworks come with their own opinions and can help remove a
| lot of those barriers.
| [deleted]
| 8organicbits wrote:
| > #5 Fast compile time... which is an advantage over Python how
| exactly?
|
| Compiled code can have fewer runtime errors, that's a big win.
| I read this as golang is better than python because it's
| compiled and golang is better than Java and C++ because the
| compiler is fast.
| mixedCase wrote:
| The advantage then is "the type system", not "fast compile
| time".
|
| And as far as type systems go, Go is one of the worst in
| mainstream usage.
| abyesilyurt wrote:
| Just curious, which languages have better type systems?
| pdimitar wrote:
| Rust, Haskell, OCaml, and many others.
|
| Golang's typing system is fairly half-done.
| mixedCase wrote:
| TypeScript, Kotlin, Scala, Haskell, Rust, Swift, modern
| Java, C#, F#, OCaml, Reason, Elm, PureScript,... it's a
| long list.
|
| I'd also count Python with MyPy, but having a mostly
| untyped ecosystem means you can't take much advantage of
| it.
| brobinson wrote:
| It's easier to list which ones don't at this point. The
| Go team ignored the last 50 years of improvements in type
| systems.
| digisign wrote:
| All of them? Minus the dynamic/weaks, such as original
| javascript.
| IshKebab wrote:
| But still better than Python's.
| kortex wrote:
| Despite its warts, Python's type system is at least
| comparable to Go, and better in several areas. The type
| inference works really well much of the time without any
| assistance, you can use tools like pyre to generate types
| for untyped code, as well as tools for discerning types
| through running the application.
|
| Heck, you can even use HKTs in Python if you are willing
| to install a plugin/library.
|
| https://returns.readthedocs.io/en/latest/pages/hkt.html
| rbanffy wrote:
| I can understand the point - compiling will do the same
| checks a type hint checker such as MyPy will do and it's a
| bit faster. I have that in my pre-push hooks, but a lot of
| people isn't used to the 90's when a compile could take
| minutes and demand a far less relaxed development pace.
| vips7L wrote:
| Javac is extremely fast. It doesn't have to do any
| optimizations.
| mmargerum wrote:
| No runtime requirement, single exe, and cross compiling were
| big one for me as well
| invisible wrote:
| Why skip on the other reasons listed? At least a few of them
| are technical in nature and don't warrant being omitted from
| your list.
| glintik wrote:
| "Performance" - looks like "I bought Ferrari instead of Hyundai
| because it faster".
| mellosouls wrote:
| #7 given Go can't compare to Python on ecosystem breadth and
| depth, its a curious choice of "reason to switch"
| chii wrote:
| the choice was a personal preference, and justified after the
| fact. This kind of justification happens way too often in a
| lot of shops, esp. if it is ran by someone with strong
| opinions and preferences.
| doctor_eval wrote:
| I took it to be a reason they chose Go over some other
| alternative to Python.
| jerf wrote:
| It's been a while since I wanted something in Go that wasn't
| available, other than the obvious big-ticket items like NumPy
| which are ecosystems unto themselves. (Or, to put it another
| way, yeah, Go doesn't have NumPy, but neither does anybody
| else other than Python at this point.) YMMV, of course, but
| it's certainly not a routine occurrence.
| [deleted]
| AnimalMuppet wrote:
| If I understand correctly, numpy at least originally was a
| wrapper around some Fortran libraries. So you could get the
| same functionality and performance in Fortran.
|
| Am I missing something? Is there some way in which numpy is
| superior to, say, Linpack (other than not having to use
| Fortran to call it)?
|
| Is there anything unique about Python that enables this
| approach? Couldn't Go, say, do the same thing? Or C++?
| dralley wrote:
| Python has a GC based around reference counting, which is
| vastly easier to integrate with native code than
| languages with heavier runtimes such as Go, Java, C#.
|
| C++ could give you equal or better performance, but it's
| not anywhere near as friendly to beginners as Python.
| Plus, the value of REPL-based programming for prototypes
| and experimentation is hard to overstate.
| jerf wrote:
| "Is there anything unique about Python that enables this
| approach? Couldn't Go, say, do the same thing? Or C++?"
|
| Network effect. I don't think anything stops most
| languages from doing most of what NumPy does (although
| IMHO even post-generics Go is actually a bad choice), but
| you have to compete with the existing NumPy. Competitors
| exist, but, well, the fact you don't know about them and
| haven't heard of them kinda makes my point.
|
| In fact in my personal opinion Python is an unfortunate
| choice for NumPy. NumPy is so big it is basically its own
| thing, and data scientists could have learned to half-
| program in almost any modern language. (Rust might have
| given them fits, and C++ would cause some issues, but
| most languages would have worked for them.)
| Unfortunately, they settled on a language with weak
| types, which makes the documentation really annoying to
| use because it's very hard to tell what will work with
| what. (I've been dipping into NumPy and pandas over the
| past few weeks, the docs are _infuriating_... it 's like,
| they make it obvious there's _something_ that will do
| what you want but it 's quite difficult to backengineer
| what that "something" is if you don't already know,
| because nothing has types anywhere. I can already tell
| you just sort of "get used to it", but it would be easier
| and faster if there was some type indications somewhere.)
| And perhaps even worse, as you scale up the size of what
| you're doing in Python, anything that _isn 't_
| accelerated becomes more and more mindbogglingly-slow,
| because when you're in Python you are in a terribly slow
| single-CPU language banged together with the highest-
| performance multi-core if not GPU-based code in the
| world, and the gap between those two things just keeps
| opening larger and larger. Knowing when you're in slow
| land and when you're in fast land takes expert-level
| knowledge and at times source code reading. I'm glad I'm
| just visiting, I think living there would drive me
| insane.
| Xeoncross wrote:
| The other packages I've missed are all Rust or C packages
| that manage to create absurdly compact or performant
| versions of low level structures and blocks like tries,
| probabilistic filters, encryption primitives, or custom
| binary storage solutions.
|
| All things that Java, Go, C# and others just can't be the
| best at because of the overhead or GC.
| dralley wrote:
| There are definitely data structures that are a massive
| pain in the ass (if not impossible) without a GC of some
| kind.
| huac wrote:
| Hmm, why exclude #4: Concurrency and Channels? Concurrency in
| Python is a nightmare; in fact, doing anything more complex
| than embarassingly parallel computation in Python is a
| nightmare. Goroutines are excellent for lots of application
| logic, especially if your operations are being blocked (e.g.
| querying a database and waiting for the response). I'll admit
| the difference is less large if you are doing big data
| computation / ETL where tasks are long-lived and you can eat
| the overhead, but the post was specifically for an
| application's web server.
|
| Also re #3 and #6 - I found learning Go to be relatively
| painless, coming from a Python background. It was helpful to
| have much more experienced teammates and to have some
| opinionated pre-existing infra (e.g. tests, lint, deploy,
| general app architecture). The lack of frameworks is good/bad
| -- more decisions to make (though the standard Go libraries
| seem to almost always be good enough) but if everyone is mostly
| using some combination of modular libraries, it means that
| problems are easier to debug and search for on StackOverflow,
| versus needing to add if the error is in Flask or Django or
| some other bespoke framework.
| gwd wrote:
| > #5 Fast compile time... which is an advantage over Python how
| exactly?
|
| I think this would probably be more why they switched _to_ Go,
| rather than why they switched _away from_ Python.
|
| Alternately, how fast are Python linters? It might be faster to
| compile Go than to run their linter (or whatever).
| mmcgaha wrote:
| Sure I am reading a bit into this but the reason they moved
| away from Python was performance. So ditching Python as a
| given, here are the reasons to select Go instead of something
| else.
| idazuwaika wrote:
| I'm considering moving away from Python as well, to compiled
| language also. Performance and single executable are my primary
| motivation. I'm tired of venv, PYTHONPATH and OS package
| dependency issues.
|
| I'm however very much reliant on Pandas and Pyarrow for custom
| ETL works. Does anyone have suggestion what language and
| ecosystem I can switch to? Preferably something simple that does
| not require cluster or JVM to avoid deployment hassles.
| kortex wrote:
| > I'm tired of venv, PYTHONPATH and OS package dependency
| issues.
|
| To both you and the peanut gallery. You should basically* never
| be using PYTHONPATH or OS packages. And there are several
| solutions to improve ergonomics of virtualenvs out there.
|
| * I've never had a legitimate use case to use OS packages and
| only one to use PYTHONPATH, which is tot temporarily set it
| during tests in a repo with multiple independent sub-packages,
| coverage reports get a bit squirrelly.
| mcdonje wrote:
| >[Go] is almost as fast as languages like C++ and Java.
|
| It seems like only a couple of years ago when Java's speed was
| the butt of many a joke. The JVM has come a long way. As someone
| who doesn't work in Java and doesn't have a horse in this race, I
| find their turnaround impressive.
| shepherdjerred wrote:
| Java has been fast for a long time. Its reputation is slow to
| recover.
| IshKebab wrote:
| I dunno I feel like the _language_ was always seen as
| fast..ish. It was the startup time, memory use, and speed of
| actual applications that were slow.
|
| Is Eclipse fast yet?
| pjmlp wrote:
| The JVM has already been quite impressive for the last two
| decades for backend computing workloads.
|
| First of all, there are plenty of implementations to chose
| from, everyone is now talking about GraalVM, because the basic
| version is free beer, yet AOT has been a thing in commercial
| Java compilers for quite some time.
|
| Nowadays OpenJDK and OpenJ9 offer JIT caches with PGO feedback
| across executions, well, OpenJDK one started in J/Rockit, and
| OpenJ9 traces back to Metrome/Websphere Real Time/J9.
|
| My first large scale Java project was done in 2005, when our
| team at Nokia Networks started the transition of a C++
| infrastruture used for base stations reporting into Java.
|
| Did Java win against C++ in microbenchmarks back in 2006, not
| at all, yet Java 5 JIT compiler in IBM J9 and Sun's JVM already
| provided enough performance juice that we could perform such
| endevour, while keeping the system responsive.
|
| Eventually some other issues plagued the project, however they
| were related with politics between the C++/CORBA folks and us
| bringing up the new platform.
| iainmerrick wrote:
| Hmm, I feel like that's been the case for more than a couple of
| years. Java has been fast for well over 10 years, I'd say.
|
| But I think Java also still has the problem that it tends to
| use a ton of memory (unless you use it the fintech way,
| manually wrangling your data in arrays rather than using lots
| of objects).
|
| My subjective impression is that garbage collected languages
| have gone through a bit of a rise and fall over time -- "GC is
| bad because it's slow!" "huh, GC is fast now" "Java is the way
| forward!" "GC uses a lot of memory" "Rust [or Swift] is the way
| forward!"
| corrral wrote:
| > Hmm, I feel like that's been the case for more than a
| couple of years. Java has been fast for well over 10 years,
| I'd say.
|
| It got the reputation in part because once upon a time Java
| programs _were_ noticeably slow and heavy on resource use, no
| matter how many times Java fans posted micro-benchmarks of
| Java finding digits of Pi to "prove" Java was fast and we
| must all be imagining things. In actual fact, in the real
| world, it was slow.
|
| I think improving hardware has more to do with its feeling
| faster now, than anything else. Hardware got fast enough that
| it no longer feels (as) slow. Plus its competition, as far as
| GUI programs go, now prominently includes Electron. On the
| server, we deploy tens or hundreds of megabytes of container
| or VM and associated overhead to run a 2MB program. So also,
| everything else has gotten far more bloated and heavy, making
| Java look better by comparison.
| digisign wrote:
| Java was slow at startup, speeding up as it is run. Those
| two were both improved, with 1000x faster hardware being
| the final leg of the stool.
| atx42 wrote:
| I think Go and Angular should have died, and would already be
| footnotes in programming history if they had not been introduced
| by Google. Let's make procedural programming great again? I get
| it, you can compile it and it has concurrency, but there's better
| alternatives in my mind, unfortunately not as popular.
| geodel wrote:
| Well those alternatives can be popular if more people find them
| better. Isn't it?
| umvi wrote:
| Procedural programming has always been great and continues to
| be great for most use cases. There's a time and a place for
| OOP, and there is a case to be made for functional programming,
| but it's hard to beat the simplicity of procedural programming.
| Go is an excellent procedural language that has lots of static
| guarantees and a super fast compile times (fast at least
| compared to C++).
| coin wrote:
| Could not agree more. Using Go is like stepping in a time
| machine and going back to 2005.
| uhtred wrote:
| Go should have died?! didn't Go come out like yesterday? This
| is why I am hesitant to invest time in new hot thing languages.
| I swear in 20 years everything important will still be written
| in C, PHP, Perl, C#, Java, Python (how could I forget
| JavaScript).
| KronisLV wrote:
| > Go should have died?! didn't Go come out like yesterday?
| This is why I am hesitant to invest time in new hot thing
| languages.
|
| Actually it came out about 10 years ago, in one way or
| another: https://go.dev/doc/devel/release So it largely
| depends on what timescales you're comfortable with - some
| people switch stacks or learn new tech every 3-5 years, for
| others this cycle is slower or faster, also depending on the
| stuff you're working with.
|
| I'd say that web dev moves quickly, embedded moves more
| slowly, the rest is somewhere in the middle for the most
| part, maybe AI/ML and certain DevOps aspects rival web dev
| speeds of innovation/churn.
|
| > I swear in 20 years everything important will still be
| written in C, PHP, Perl, C#, Java, Python (how could I forget
| JavaScript).
|
| Perhaps, i think languages like Rust will be pretty
| widespread, both in the Linux kernel, as well as many tools
| and whatnot, albeit in a different and perhaps more
| conservative fashion than currently (the "rewrite everything
| in Rust" craze). In contrast, most of the modern web based
| SaaS solutions will be dead, most certainly the majority of
| Kubernetes tooling out there.
|
| Go might just be boring and useful enough to stick around and
| join the dreadful bunch of languages used in maintaining
| legacy code. It's funny, though, because while the languages
| themselves are more usable than they were 10 years ago,
| people's sentiments (including mine) are largely influenced
| by how many bad codebases they have to maintain:
| https://earthly.dev/blog/brown-green-language/
|
| On an unrelated note, it would be pretty cool to have
| extremely slowly moving and stable languages, projects and
| tooling out there. To see maybe 3 or 4 releases in my entire
| lifetime and to have the next generation take over the
| burden. Then again, seeing how COBOL and FORTRAN are now,
| perhaps that sense of grandeur isn't worth the effort and old
| projects should just die.
| uhtred wrote:
| > On an unrelated note, it would be pretty cool to have
| extremely slowly moving and stable languages, projects and
| tooling out there. To see maybe 3 or 4 releases in my
| entire lifetime and to have the next generation take over
| the burden. Then again, seeing how COBOL and FORTRAN are
| now, perhaps that sense of grandeur isn't worth the effort
| and old projects should just die.
|
| Isn't that Perl?
| KronisLV wrote:
| Kind of, though the whole Raku thing made everything a
| tad wonky.
|
| Some of the nicer Perl software that I use currently is
| BackupPPC, which has been pretty solid despite the
| slightly subpar UI: https://github.com/backuppc/backuppc
|
| And another interesting piece that I can think of was
| RemoteBox, which was pretty niche but still worked
| nicely: https://remotebox.knobgoblin.org.uk/?page=about
|
| From the more popular packages, one should also mention
| exiftool, which was written in Perl:
| https://github.com/exiftool/exiftool
|
| Probably also a lot of other pieces of software, though
| it doesn't seem like there's much of a large/active
| community around Perl, for example, have a look at:
| https://github.com/trending/perl?since=monthly and then
| compare it to something like:
| https://github.com/trending/go?since=monthly
|
| In regards to other contenders, I think
| FreePascal/Lazarus should also be mentioned, since
| they're pretty stable, capable and perhaps some of the
| better ways to write desktop software!
| uhtred wrote:
| I had no idea exiftool was writen in Perl!
| KronisLV wrote:
| Here's a few other tools that are written in Perl, sorted
| by GitHub popularity: https://github.com/EvanLi/Github-
| Ranking/blob/master/Top100/...
|
| Actually, that repo has lists like this for most
| languages: https://github.com/EvanLi/Github-Ranking
| bloblaw wrote:
| Go was released in 2009, which is 13 years ago. Many
| companies have built significant portions of their stacks on
| top of Go....Twitch, Google, Uber, Lyft, Amazon, etc.
|
| It's widely used in industry and isn't going anywhere.
| oceanplexian wrote:
| I worked at one of those places and helped rewrite
| components into Go ;) Sure, there were performance benefits
| but in my experience there was never a real business
| problem that Go solved that Python couldn't.
|
| All the people freaking out about performance didn't
| realize that even in the Python days, half of our
| datacenters pretty much sat idle or severely underutilized.
| Computing is dirt cheap as long as you're not renting a
| 15-year-old CPU from a Cloud Provider for 100x markup. The
| other thing is that engineers would frequently build things
| that were just wasteful or unnecessary, and sure, Go sped
| things up, but you could have changed the design instead of
| the language.
| feffe wrote:
| Go 1.0 was released in 2012, it spent 3 years in alpha/beta
| phase.
|
| https://go.dev/blog/go1
| gnulinux wrote:
| > I swear in 20 years everything important will still be
| written in C, PHP, Perl, C#, Java, Python (how could I forget
| JavaScript).
|
| Hmm all the languages you listed have certain niches that I
| think will likely remain alive in the next 20 years, except I
| don't think Perl deserves this spot. I think anything Perl is
| a great fit at, Python will also be a great fit and
| (subjectively) python code ends up being strictly more
| readable than perl.
|
| I would guess PHP also has a similar relationship to Python
| but the effect, I believe, is a lot milder as PHP shops seem
| to be more decisive about sticking with PHP. All evidence
| anecdotal of course.
| joebob42 wrote:
| I think it should have died when it came out. Javas way older
| but I'd rather use that.
| dgb23 wrote:
| There is plenty of important stuff written in this
| generation's languages like Go, Clojure, Rust, Typescript and
| so on. You might be relying on some of them.
| akira2501 wrote:
| I have yet to find a language where cross compiling is as easy
| and simple as it is with Go. It's a first class feature of the
| language and for my use case, it makes it an obvious choice.
|
| Programming is about managing tradeoffs to solve real problems,
| not building a perfect ideological environment to write code
| in.
| josephcsible wrote:
| Indeed. My overall complaint about Go is that despite being a
| very new programming language, it hasn't incorporated a lot of
| lessons learned long ago (e.g., the billion dollar mistake).
| One of my favorite articles about Go is
| http://cowlark.com/2009-11-15-go/
| hnov wrote:
| As a PL Golang is very unremarkable and it does have a lot of
| special casing and a general lack of "orthogonality," in fact
| it reminds me of PHP in some ways.
|
| However, that's completely missing the point: Golang brought
| CSP into the mainstream when most were still using CPS to
| scale beyond OS threads. The kind of people who rewrite
| services to get performance improvements and then write blog
| posts about it aren't gonna learn your complicated language
| (just like they're not gonna spend their time messing with
| gevent and profiling to scale their python): they're makers
| not PL researchers. Google rightly noticed that there's a
| huge gap between existing mainstream offerings on the ease of
| use-performance spectrum and filled it with a DSL for
| programming network services. It doesn't need to be fancy, it
| needs to allow someone with CS201 knowledge to set-up the
| codebase so that people with CS101 knowledge can write
| _sequential_ code that talks to the network without
| callbacks, yield /async/await or any of that incidental
| cruft.
| hnov wrote:
| Go is incredibly productive. Its primitive type system keeps me
| from bikeshedding, the standard library mostly makes sense,
| builds are fast, and yes, the builtin asynchronous IO means
| that I can write a C10K server without even trying. No JVM, no
| choosing between libuv and libevent, literally just take the
| simplicity of the fork-per-request model and adapt it to
| modernity.
| Xeoncross wrote:
| For a lot of people like me, Go was something of a better
| scripting language.
|
| It wasn't as hard to grok as C or Rust, it wasn't as slow as
| Ruby, Python or PHP. most of all, it it was designed to make
| use of multiple cores. Surprisingly, having testing and
| formatting built into the tooling is also a huge win after
| spending years debating and changing choices in scripting land.
|
| Go is the new PHP/Node.js and Rust is the replacement for
| everything else. I know this is technically wrong, but that's
| how it feels.
| tech_tuna wrote:
| Agreed 100%. I've used a bunch of languages over the years:
| C, C++, C#, VB, Perl, Java/Groovy/Kotlin, Javascript, Lua,
| Ruby, PHP, Python and Go. All fairly mainstream and I'm not
| going to start railing on the ones I don't like. . . so let's
| just say Python was the first language that I loved and Go is
| my current favorite.
|
| For me, readability, simplicity and having compile time
| checks are wonderful. Go feels like a better Python. I still
| enjoy using Python but "runtime is funtime" even with type
| hinting and linting and everything else.
|
| I am also a sucker for good tooling and a pleasant dev
| experience. Go has fantastic tooling. That being said, it has
| its warts and weak points. If I need to write something quick
| and dirty, I prefer Python. If I need to parse JSON and I
| don't have an easy way to generate client code, I prefer
| Python.
|
| There are some quirky bits in Go I don't particularly like
| e.g. the reversal of parameter type and name in function
| signatures. . . that just confuses me because I typically am
| using 2-4 different languages in any given week and Go is the
| weirdo in this regard. :)
|
| I would be thrilled to see Rust become the dominant systems
| programming language some day. I'm planning to learn it as
| soon as it looks like the right choice for me - for most of
| my work, Python + Go + bash (I love and hate bash) are more
| than sufficient.
| Sohcahtoa82 wrote:
| > I still enjoy using Python but "runtime is funtime" even
| with type hinting and linting and everything else.
|
| I'd love to see a strong statically-typed Python that could
| throw type errors at compile time. I've only taken
| advantage of the duck typing once, and the way I did it was
| a massive code smell and I ended up refactoring it out
| anyways.
| robertlagrant wrote:
| Mypy gets you a lot of the way there.
| kortex wrote:
| You mean statically typed? Python is already strongly
| typed.
|
| Try running it through mypy with all the strict options.
| If you can get it to 100% pass and don't try to "cheat"
| the system too much with dynamic casts, I think you will
| find runtime type errors to be very rare.
| Sohcahtoa82 wrote:
| > You mean statically typed? Python is already strongly
| typed.
|
| Err...yes. I forget that "strong" and "static" are not
| the same and that "strong" and "duck" are not mutually
| exclusive.
| crowdyriver wrote:
| My feelings exactly. I love go because of how productive and
| resilient can be. In months programming in it I've barely had
| any null pointer exceptions. If it compiles, and passes the
| linters, it mostly works aswell.
| [deleted]
| simonw wrote:
| What's better than procedural programming?
| tnzk wrote:
| I assume he implied functinal programming.
| KronisLV wrote:
| What's wrong with Angular? It being largely "batteries
| included" seemed pretty nice and I really liked the fact that
| TypeScript was a first class citizen - React and Vue both feel
| like it's been kind of tacked on, especially when a lot of
| additional libraries out there don't really have proper
| bindings.
|
| That said, personally I also think that React kind of went
| downhill for a bit due to the hooks (after seeing a few
| projects become really nightmarish to debug due to render loops
| without clear causes for them, after people sprinkled one too
| many hooks in there).
|
| Oh, and the Vue 2 to 3 migration is also a bit problematic
| because still many UI component libraries haven't been migrated
| over - currently actually using PrimeVue on a project because
| BootstrapVue still doesn't have proper support
| https://github.com/bootstrap-vue/bootstrap-vue/issues/5196
| gosukiwi wrote:
| No matter how hard I try, I just can't like React. I prefer
| Angular, Vue, even Ember. React feels like a downgrade to me.
| pkulak wrote:
| I can't think of anything off the top of my head that doesn't
| require a runtime, but does exclusively use green threads.
| BipolarCapybara wrote:
| What do you feel is a good alternative to Go?
| bloblaw wrote:
| Depends on your requirements. If you want statically compiled
| (AOT compiled), then I think Nim, Zig, or even Rust are good
| alternatives.
|
| If you like the high-performance backend, then Java, Kotlin,
| Scala, or C# are great choices.
| sk1pper wrote:
| Do you mean for production? Zig isn't production-ready. Nim
| is extremely niche. I'm kind of puzzled why I see these
| thrown around so much on HN. Sure, they're fine for a side-
| project, but they're pretty out there for anything mission
| critical.
| bloblaw wrote:
| Go is successful because it has many appealing features:
| 1. trivial cross-compilation 2. native multi-threading
| (eg no GIL or multi-process hacks) that is easy to take
| advantage of 3. fast. An order of magnitude faster than
| Python in many cases. 4. easy to deploy. Most often just
| a single binary
|
| I like Go because once I compile it, I can ship that binary
| anywhere and it will run. I like Python for a great number of
| tasks and for prototyping, but I prefer Go when I need to run
| my code on another machine (or it needs to be fast).
|
| To put it simply, with Go I ship a binary. With Python I have
| to ship my entire development environment.
| wiz21c wrote:
| How fast is it compared to rust ? Do you know.
|
| I ask because I've started a side project in rust because all
| of its guarantees were appealing to me (I don't want to spend
| too much time on bugs, and my code uses some threads). I also
| need maximum performances. So I've chosen it. But now I have
| my compilation times that reach 45 seconds, so I'm slowly
| wondering if the go balance (towards fast compilation) would
| not be more advantageous; unless of course, performances are
| real bad...
| lupire wrote:
| Why do you need maximum performance?
|
| Logically, if you need maximum performance, you can't care
| about compile time.
| cogman10 wrote:
| There are a bunch of different metrics for performance that
| it is a little hard to compare.
|
| Rust will have faster CPU and memory performance. It has no
| GC (well, other than RC). If you are IO bound, there won't
| be much of an appreciable difference, assuming you are
| using Rust's async/await for stuff. If you are using
| threads directly, then it will be a lot easier to make
| goroutines faster for IO stuff.
|
| The long compile time of rust has a lot to do with it's
| LLVM backend, which is ultimately generating pretty fast
| code. You don't get that with go (well, unless gollvm
| lands). Go traded execution speed for compile speed by
| doing their own compiler/optimizer. Generally speaking,
| that doesn't really matter (hence the reason python is
| popular).
| snapetom wrote:
| As someone who has started side projects with very
| technical and opinionated friends, just stick with Rust.
|
| Make a decision, stick with it, ship it. If there's a real
| problem, change it after you have it up and running.
| There's no point in optimizing for millions of users if you
| have 0 users now.
| wiz21c wrote:
| yeah sure, I have zero user and well, it may be like that
| until my death :-)
|
| that project was an excuse for learning rust. But now I
| understant rust a bit more, well, I'm a bit scare to wait
| 45 sec on each build for a side project (ie a project I
| do on my very limited spare time) :-)
|
| but anyway, rust is really cool to work with (I have a
| python/C++/assembler/R background). The level of checking
| it does is really mindblowing (and frustrating at times
| :-))
| estebank wrote:
| Try to debug where your compile times are going[1][2],
| but if you want a good rule of thumb: separate your crate
| into multiple if you can (that way incremental
| compilation will yield better results), switch to an
| alternative linker, like mold or lld, and use trait
| objects instead of generics (monomorphization can be
| expensive during compilation, while trait objects can be
| slower at runtime, but not enough to be worth it worrying
| about it).
|
| [1]: https://fasterthanli.me/articles/why-is-my-rust-
| build-so-slo...
|
| [2]: https://matklad.github.io/2021/09/04/fast-rust-
| builds.html
| didibus wrote:
| Go is slower than Rust. Rust allows you to go as fast as
| the metal can get you if you want.
|
| But Go is still reasonably performant and has a reasonably
| low memory footprint. We're talking C#/Java level
| performance with C level memory footprint.
|
| Rust is the next level up in performance.
| throwaway894345 wrote:
| It's about on par with Java and C#, which is roughly in the
| ballpark of "half as fast as Rust/C/C++". If your goal is
| to spend less time programming overall, Go is great for
| most applications. If your goal is to spend 10% less time
| fixing bugs and 100% more time writing code, Rust is great
| for most applications. :) Of course those figures are made
| up, but in my experience they're in the right ballpark (I
| like both languages, but if I actually want to get
| something done in a reasonable timeframe I always end up
| using Go).
| igouy wrote:
| How fast to do what?
|
| _fwiw_ https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| Gwypaas wrote:
| Consider turning your crate into a workspace instead. That
| usually helps to keep the compile times manageable.
| snapetom wrote:
| The two things I always bring up in interviews on why I like
| Go:
|
| 1) Easy to use pointers. There's just pointers, not like C
| where you can have anywhere from 4 to 8 different types
| depending on your platform. And no, pass by reference vs.
| value are not the same as pointers.
|
| 2) Very simple to use concurrency.
| mb7733 wrote:
| > 1) Easy to use pointers. There's just pointers, not like
| C where you can have anywhere from 4 to 8 different types
| depending on your platform. And no, pass by reference vs.
| value are not the same as pointers.
|
| Do you mean C++? Or am I confused?
| snapetom wrote:
| Null, void, wild, dangling in core C. DOS also had far,
| near. I believe one of the Windows Visual something
| platforms had extensions that added another three or
| four.
| bornfreddy wrote:
| I'll bite. So null is just a special value one can assign
| to a pointer, marking it not used. In Go this is nil.
| Void means "absence of type" and is related to pointers
| only marginally - void* is a pointer to something we
| don't know a type of. In Go, I guess a pointer to
| interface{} would be the same? (Not quite, but close)
|
| As for wild and dangling pointers (I would argue the are
| the same - pointers that show somewhere they shouldn't),
| fair point. Of course one would expect this from a
| language so many decades younger.
|
| But none of these are pointer "types" (far and near
| arguably are - iirc they determine the size of a pointer
| - but these four are not). I hope the question on the
| interviews are posed differently, I for one wouldn't know
| what you mean.
| didibus wrote:
| Ya, and if you look at the language space, there's nothing
| else that offers #1.
|
| That set of features isn't related to the language itself
| (though the language was designed to allow those features).
|
| This is where Go is appealing, it's not the language itself,
| it's the properties it brings with it. Cross-compilation,
| multi-spec, reasonable performance and low memory footprint.
| Single binaries. And I'd add fast compilation times.
|
| Honestly it needs more competition that offers those same
| properties, because I'd love to have more choice of language
| (syntax + semantics), but get the same properties. But for
| now, you have to use Golang if you want something that gives
| you all those properties and that's just where Golang
| differentiates itself.
| bloblaw wrote:
| That's a great point, and one I hadn't considered. One
| language feature that Go brings is first-class multi-
| threading and communication amongst and with child threads.
|
| The only languages I know that can compete with Go with
| similar properties are Nim, Zig, and Rust. I'd like to
| include Delphi / Free-Pascal, but cross-compilation can be
| a bit of headache at times.
| xigoi wrote:
| Nim has all these properties. (I'm not sure about threading
| because I don't use it much.)
| [deleted]
| marban wrote:
| Anyone got some basic Go equivalents for web scraping at hand?
| Requests/httpx, beautifulsoup, etc.
| erik_seaberg wrote:
| > Developer Productivity & Not Getting Too Creative
|
| These stories seem to have an undercurrent of mistrusting the
| judgment of your expensive and carefully chosen staff. It's not
| doing anyone any favors to force an expert to laboriously write
| out the same junk a novice would have.
| timcavel wrote:
| gosukiwi wrote:
| I remember playing with Go trying to write a little dynamic
| programming language. The lack of generics made it painful, but I
| should give it another shot sometime :p As a web developer, I
| appreciate Go's simplicity, and ability to be "close to the
| metal" without having to worry about memory, like in C, or know a
| complicated language, like Rust.
| throwaway894345 wrote:
| I never had any issue with the lack of generics in making a
| programming language, but the lack of sum types was painful.
| papito wrote:
| "Developer productivity and not getting too creative" is NOT a
| point in favor of Go. Go does not have a lot of batteries
| included. Things like error handling, logging, test
| bootstrapping, etc, require consensus on the team and tight
| coordination. Every project is basically its own framework. Most
| teams are not that well-oiled.
|
| They are going to find this out the hard way.
|
| And fast? Please. If your database queries are a mess, or if you
| have no discipline elsewhere, it doesn't matter what language you
| use - you will blow right past the "superfast" baseline.
| s17n wrote:
| Go provides error handling and logging.
|
| It's true that if what you're writing is an application server
| consisting of business logic and glue code that delegates all
| the "heavy lifting", performance won't be the first concern.
| However, even in this case, I think you'll find its easier to
| get sub-second response times in Go than in a language like
| Python.
| kabdib wrote:
| Recent-ish experience:
|
| - Wrote a distributed app in Python (it aggregated a few GB /
| day of info from several thousand servers). Performance was
| terrible, though I was doing all the right things (async I/O,
| etc.).
|
| - Rewrote it in Go. That worked really well, and took just a
| few days. But management freaked out, forbade Go in
| engineering, and so:
|
| - Spent several months rewriting the whole thing in C++. What a
| fucking misery. Just getting HTTPS working was a depressing
| experience. Package manager? No, you get to trawl the internet
| for semi-busted projects that sorta kinda maybe work, and then
| bend them to fit.
|
| Go is the sweet spot between "Python isn't fast enough and
| never will be" and having to reinvent the wheel in C++.
| huac wrote:
| Did you have prior Go experience to the rewrite? My
| experiences line up with this quite closely, similar tasks
| are much better suited to Go, concurrency management is night
| and day vs Python. But Go can seem scary to folks without
| previous experience and that turns lots of folks off - even
| though the language and syntax don't feel _that_ different
| and there is a similar batteries included approach, though
| Go's batteries are generally better.
| dgb23 wrote:
| > But management freaked out, forbade Go in engineering
|
| It pains me to read this, especially since Go seems to be a
| language that is extremely easy to adopt.
| AnimalMuppet wrote:
| Management _forbade_ the use of Go? But they allow both
| Python and C++? So their rationale for forbidding Go is...
| what?
|
| Is this just cluelessness and management by familiarity with
| buzzwords?
| sliken wrote:
| Heh, imagine you have 8 C++ programmers, then one rewrites
| some critical piece in Go ... and then leaves. Now you have
| to find a go programmer (from a much smaller pool). How do
| you find a good one? It's not going to be easy without some
| good Go developers on the interview panel. Say you hire
| one, he goes on vacation for 2 weeks, something important
| breaks and you need a 2nd go programmer, etc.
| dgb23 wrote:
| I have a bit of a different take on this.
|
| They mentioned it was a rewrite that happened in a couple
| of days in a shop that uses C++ and Python (at least). We
| can assume it was a small to medium utility program.
|
| Someone who can write C++ and Python professionally will
| get up to speed with Go in a few days. This shouldn't be
| a hiring issue. The cost of rewriting it again in C++ can
| easily be higher and apparently was a huge PITA. Go is
| not some obscure language, it is literally designed to be
| accessible by anyone with basic programming experience.
| sliken wrote:
| As a programmer I agree, but as management that's a hard
| thing to tell. If you were the boss would you allow Lisp?
| Scheme? Erlang? It sounded like a pretty important piece
| of code, even if small. The complaints about being forced
| to do C++ and how painful that process was shows that
| it's at least non-trivial.
| AnimalMuppet wrote:
| I disagree. If you're managing programmers, you _might_
| be expected to have a bit of a clue about programming
| languages. If you can 't tell how easy it would be for
| your people to pick up Go versus how easy it would be to
| pick up Lisp, you have no business managing programmers.
| dgb23 wrote:
| Well you can still manage programmers but you certainly
| shouldn't micromanage their technological choices then.
| stayfrosty420 wrote:
| Very surprised this is getting downvoted, I think in two years
| from now everyone will be singing this exact song when the next
| flavour of the month arrives.
| sliken wrote:
| Heh, flavor of the month ... for a 12 year old language.
| rat9988 wrote:
| Reason 2 - Language Performance Matters For many applications,
| the programming language is simply the glue between the app and
| the database. The performance of the language itself usually
| doesn't matter much. Stream, however, is an API provider
| powering a feeds and chat platform for 700 companies and more
| than 500 million end users. We've been optimizing Cassandra,
| PostgreSQL, Redis, etc. for years, but eventually, you reach
| the limits of the language you're using. Python is a great
| language but its performance is pretty sluggish for use cases
| such as serialization/deserialization, ranking and aggregation.
| We frequently ran into performance issues where Cassandra would
| take 1ms to retrieve the data and Python would spend the next
| 10ms turning it into objects.
| steve_adams_86 wrote:
| The last time I was on a team using Go, we ended up ditching it
| for these reasons.
|
| We realized it took about as much specialization and wheel
| reinventing as Rust, which offered way better developer
| ergonomics in ways that mattered to us and wouldn't panic over
| things that weren't easy to predict or caught by the compiler.
|
| There were still tons of trade offs, but it worked well for us.
| Go is cool but I still can't seem to figure out where and when
| I'd prefer it most of all... Especially the poor error handling
| and lack of safety. These things really drive me crazy.
| uh_uh wrote:
| I prefer Go when I want more safety/performance than Python
| but less ceremony than Rust.
| stayfrosty420 wrote:
| I think the latter point about "less ceremony" is extremely
| debatable especially on a larger project.
| uh_uh wrote:
| How does Go have more ceremony than Rust without a borrow
| checker, lifetime annotations and all?
| adolph wrote:
| _This is why languages like Go offer automatic dynamic
| memory management, or more simply, garbage collection._
|
| https://medium.com/safetycultureengineering/an-overview-
| of-m...
| mynegation wrote:
| I think the point is not that Rust has less ceremony (it
| certainly has more), but that you want the "ceremony" for
| larger scale projects.
| SideburnsOfDoom wrote:
| related, how does having no unit tests have more ceremony
| than a full test suite?
|
| (and yet it will do so, as you try to find other ways to
| make your code safe to release)
| steve_adams_86 wrote:
| Fair enough, there are certainly cases where Go is an
| awesome tool to use.
| corrral wrote:
| > If your database queries are a mess,
|
| This has been the cause of basically all of the slowness in
| Rails projects I've worked on, at least. I've seen queries
| taking _tens of thousands_ of times longer than they should.
|
| I don't think I've ever seen a Rails codebase that didn't have
| speed problems, but every single time it's been because DB
| access is being done very inefficiently. I've yet to see one
| actually bound by the computational speed of Ruby (I'm sure it
| happens, though) and it's considered way on the slow end of
| popular languages.
|
| The problem's always 1) Doing shit in Ruby that the DB can do a
| thousand times faster (joins[!], calculating things based on a
| huge number of rows, mashing together pieces of data, et c.)
| with a better query, or 2) firing tons of identical-but-for-
| some-values queries in a loop(!?)
|
| [EDIT] Actually, just as I hit post, it occurred to me that 2
| is really just a flavor of 1.
| papito wrote:
| The "query in a loop" thing happens a lot. This is the danger
| of hiding databases behind magical frameworks and ORMs. Some
| developers don't understand the _basic_ idea that a single
| database query with execution time and the network roundtrip
| can destroy your app performance. They literally treat all
| ORM code as "free".
| tgv wrote:
| > If your database queries are a mess
|
| This is a "wut?" moment for me. Why add this external factor,
| when it's totally irrelevant and the article doesn't even
| mention it?
| KhalPanda wrote:
| I wouldn't say totally irrelevant. I've worked on many line-
| of-business applications and websites where the database is
| the bottleneck. People love to obsess over "what language?",
| happily ignoring the fact database access is 90% of the
| request time.
___________________________________________________________________
(page generated 2022-05-26 23:02 UTC)