[HN Gopher] Bun v0.5
___________________________________________________________________
Bun v0.5
Author : cyclecity
Score : 219 points
Date : 2023-01-18 18:09 UTC (4 hours ago)
(HTM) web link (bun.sh)
(TXT) w3m dump (bun.sh)
| viksit wrote:
| as a newbie to bun, is there a reason to use it beyond it being
| an alt to node/deno?
|
| i mean, i don't know how many people even use deno, let alone
| bun.
| Alifatisk wrote:
| Makes me happy seeing newer alternatives to Node, it's exciting!
| thiago_fm wrote:
| Anybody care to explain on how it achieve such numbers in
| comparison to node and deno?
|
| Why would anybody not use Bun, other than the cost of migration,
| given the performance improvement?
|
| Nevertheless, amazing performance. Feels refreshing to see more
| improvements to the JS/TS community.
| EGreg wrote:
| I would ask the other way ... why use Bun if the other products
| are mature and good enough? I've seen Node forked (to Deno I
| think) and then eventually they merged it back.
| klohto wrote:
| Node forked to Deno? And merged... back? What are you talking
| about?
| zdragnar wrote:
| You might be thinking of io.js, which was a fork almost
| entirely due to politics. The advisory board came out of it,
| and a push for semver, but it started here: https://github.co
| m/joyent/libuv/commit/804d40ee14dc0f82c482d...
| ramesh31 wrote:
| >I've seen Node forked (to Deno I think) and then eventually
| they merged it back.
|
| You're thinking of the io.js debacle
| kamikaz1k wrote:
| Jarred is approaching this from a fundamentally performance
| (due to targeting of Edge runtime) and DX perspective. If you
| follow his twitter or bun discord, you can see he spends an
| enormous amount of time studying, profiling, and tweaking
| features so he can squeeze as much performance out of it as he
| can.
|
| Reasons not to use bun:
|
| - it is pre v1, so unstable API
|
| - it is unstable, so you will deal with crashes
|
| - newer, so help articles will be hard to find
| culi wrote:
| I think the main difference is that while Node and Deno embed
| Chrome's V8 engine, Bun embed's Apple's JavaScriptCore. Bun
| also uses "a new JavaScript parser based on esbuild's
| JavaScript parser but ported to Zig"
|
| However, it's worth noting that those benchmarks have been
| critized a lot for being cherry-picked and not very
| representative of real-world use-cases
|
| I've tried to look it up a number of times but I've yet to come
| across any benchmarks done by an independent party (please
| share if you find some)
| franciscop wrote:
| It's worth noting that the main people I've seen complaining
| about those benchmarks were people working on Deno or Node :)
| hajile wrote:
| In my general experience, JSC is 20-50% faster in a lot of
| things, but uses about 2x the memory. I'm not sure how much
| of that is memory/speed tradeoff, but I suspect a lot of it
| is "we spent our budget on fast and skipped working on a
| better garbage collector".
|
| It's probably a decent tradeoff in a lot of applications, but
| probably not in all of them.
| gardenhedge wrote:
| I see Oven (creator's of Bun) are hiring. I imagine the pool of
| javascript developers that they could hire from is tiny. Add in
| Zig and it's even smaller.
| aphexairlines wrote:
| They don't have to hire people who already know Zig -- just
| people capable of learning it.
| pictur wrote:
| why is this project constantly benchmarking against deno and
| node? it seems to attract good attention this way but I wonder
| what else it offers besides performance.
| intelVISA wrote:
| easy targets I would guess
| vexna wrote:
| Because its for running server side javascript, just like
| node/deno. It would make sense to compare itself to its
| competition.
| francislavoie wrote:
| Because it's positioning itself as a faster, leaner, modern
| drop-in replacement for Node.
| kamikaz1k wrote:
| what else would you see it compared to?
| davesnx wrote:
| versus other than JavaScript stuff: Java, C++, OCaml or Go
| mmmeff wrote:
| Awesome to see workspaces get some love, but kinda odd they
| shipped it without support for globs. Guess I'll keep waiting to
| try it out on my projects.
| Jarred wrote:
| We'll add glob support in v0.6. We didn't include it because we
| need to implement a glob matcher in native code and we needed
| to descope some stuff because it was already a little more than
| 3 weeks since the last release
| lhnz wrote:
| You might be interested in @devongovett's `glob_match`
| library (written in Rust):
| https://github.com/devongovett/glob-match
| msoad wrote:
| Does Bun also generate standalone executables? I'm interested in
| using it for CLI apps.
| muhammadusman wrote:
| As is with all things in the JS world, I usually ignore new
| things until they have some traction.
|
| Is Bun ready to be used for production projects?
| wetpaws wrote:
| Ahaha no
| maherbeg wrote:
| Is there a roadmap to getting to a 1.0 stable release?
| wdb wrote:
| Starting to look promising. Work projects not working yet due to
| the need of `dgram` and `async_hooks`.
|
| Would leveraging `async_hooks` be possible in the future with the
| used non-v8 engine or would there be some alternative?
| Jarred wrote:
| dgram & UDP sockets will happen, though honestly probably not
| until v0.7
|
| We'll likely do AsyncLocalStorage and make the rest of
| async_hooks a no-op. async_hooks are detrimental to event loop
| performance, but important for observability tooling. I think a
| better approach here is designing a more specific API for the
| top usecases
| stephen wrote:
| Amazing. Getting just AsyncLocalStorage and the rest of
| async_hooks later / or not all would be great, as that's
| currently blocking us from bun.
|
| Really appreciate the pragmatic approach!
|
| (Instead of being dogmatic like "we just can't/won't deliver
| async_hooks unless its exactly right", so then it never
| happens.)
| xg15 wrote:
| Really appreciating bun's ability to set custom WebSocket
| headers.
|
| Incidentally, what's up with the resistance against this from the
| standards maintainers? [1]
|
| The request exists since 2017, there are tons of use cases and
| developer interest, but Chrome refuses implementation on
| technicalities. What gives?
|
| [1] https://github.com/whatwg/websockets/issues/16
| gmaster1440 wrote:
| Seeing the perf benchmarks for `vite build` with and without bun
| will be the ultimate practical test of bun for me, excited for
| the next release where we'll hopefully see that support.
| 1vuio0pswjnm7 wrote:
| Please add musl build here:
|
| https://github.com/oven-sh/bun/releases/expanded_assets/bun-...
| Jarred wrote:
| The last time I looked into adding musl support, there were
| some difficult to narrow down crashes in bun's linux aarch64
| build
|
| it's worth revisiting though since its been a little while
| Jarred wrote:
| I work on Bun. Happy to answer any questions or feedback
| leidenfrost wrote:
| How far is Bun to run a NestJS project? (Leaving adapters like
| Mongo aside)
| 999900000999 wrote:
| Like with any promising project, what are the downsides ?
|
| How are you funded? Is speed enough of a concern to take a risk
| on using this vs Node ? From my experience with Node your lucky
| if it works at all, I don't know if I'd like to add another
| variable when things go wrong.
|
| I can't imagine this supporting every single npm module.
|
| That said, god speed. If you can really make JavaScript fast as
| a complied language, I and many other JS devs will be happy.
| jonasb wrote:
| Will Postgres.js be the way to go for using Postgres, or do you
| expect to build a custom Postgres client library?
| Jarred wrote:
| We will eventually have a builtin Postgres client, but
| Postgres.js is also a great choice. I started to work on a
| `bun:sql` module, but ran out of time for now.
| danielEM wrote:
| Out of curiosity - how do bun plan on monetization? Is that
| even possible in the age of node.js, deno and who knows what
| else? :-)
|
| I mean, I wish bun all the best, but trying to wrap my head
| around - who the heck and on what basis gave to bun project a
| money :-)
| TAForObvReasons wrote:
| Hosting is the obvious answer. Deno is monetizing in the same
| exact way (https://deno.com/deploy/pricing) and they managed
| to raise much more money with the same playbook.
| christkv wrote:
| Is it possible to connect to Mongodb yet?
| Jarred wrote:
| Not yet. MongoDB requires resolving SRV dns records and we
| haven't implemented support for that yet (just A/AAAA via
| getaddrinfo()-like APIs currently)
|
| Tracking issue: https://github.com/oven-sh/bun/issues/1822
| christkv wrote:
| Awesome thanks for answering it.
| danielEM wrote:
| And a side note, before got to this thread was looking into bun
| code and saw your commits, you're very productive man,
| congrats!
| detrites wrote:
| Are there any plans for a REPL?
|
| And thanks for bun! It's been impressive and inspiring to
| watch.
| Jarred wrote:
| This is something we need to do, but haven't prioritized yet
|
| For now you can do bunx bun-repl
| Yahivin wrote:
| Civet just added a bun loader
| https://github.com/DanielXMoore/Civet/blob/main/source/bun-c...
|
| I'm curious to hear your thoughts about Bun/Civet integration
| to explore improvements to the language frontend as well as the
| language backend?
| edvards wrote:
| What's the most challenging thing you had while working on the
| project so far? It seems like the project has a pretty complex
| goal, so I wonder what things were the more difficult ones for
| you
| Thaxll wrote:
| What was the decision making of chosing Zig for Bun, a very
| promising but immature language?
| Jarred wrote:
| Zig is great for writing fast software and I'm really
| productive in Zig.
| thayne wrote:
| Are you worried about breaking changes in zig requiring
| large changes in bun, or getting stuck on an old version of
| zig?
| tiffanyh wrote:
| Any plans to collaborate with just-js?
| ushakov wrote:
| I have a question. Does Jarred ever have a vacation? Really
| concerning to see how much you work lately. Wishing you a more
| relaxed time
| mattlondon wrote:
| Is there a migration guide for Deno users?
| MuffinFlavored wrote:
| do you think it might be too "living on the cutting edge" to
| adopt this yet?
| Jarred wrote:
| Not yet, we haven't released our docs site yet either.
| Probably won't be there in the first release of our docs, but
| this is something we should do
|
| If you're familiar with Node, Bun should feel familiar except
| you don't need as much tooling to use it.
|
| Things like TypeScript, jsx, loading .env files, Jest-like
| test runner etc just work. You can use the builtin
| TypeScript/JS LSP in your text editor instead of installing a
| separate extension. You can import packages from npm without
| the "npm:" specifier. It's worth mentioning that Bun doesn't
| support HTTPS imports yet, so you'll need to use npm - but
| bun has a very fast builtin npm client. Like deno, you can
| often skip running `bun install` or `npm install` entirely
| for bun because bun will automatically install dependencies
| from npm when there is no node_modules folder
| deworms wrote:
| [dead]
| henry_viii wrote:
| A couple of reasons that contribute to Bun's performance are:
|
| 1) using JavaScriptCore instead of V8
|
| 2) porting esbuild from Go to Zig
|
| I have a couple of questions about (2):
|
| 1. How long did it take you to port esbuild?
|
| 2. Why did you choose to port esbuild to Zig instead of another
| language e.g. V?
| kamikaz1k wrote:
| Jarred didn't port esbuild, his vision/ambition is far beyond
| that for bun. But even as a transpiler, Jarred made different
| decisions about the compilation process. Also time doesn't
| really mean the same thing, this brosef works 80hrs/week on
| this stuff, and he's been doing that for over a year.
|
| He chose Zig because it's a good language for performance
| sensitive applications and found himself to be very
| productive in it.
| culi wrote:
| Not a question, mostly a comment. Excited to see the crypto
| speed improvements. Makes me hopeful about projects like
| scikit.js[0] toppling Python's ML dominance
|
| [0] https://scikitjs.org/
| adenozine wrote:
| What scientist is going to want to write JS when they can
| choose Python?
|
| I've worked with hundreds of scientists from different
| domains over the past two decades and I've literally never
| once heard of wanting to use Javascript for anything remotely
| scientific.
|
| Furthermore, given that WebAssembly seems poised to
| (eventually) make strides in how browser-oriented
| applications are built then the logical conclusion is a sort
| of reduce function on languages where you choose the language
| that's the most pleasant to write and maintain since you will
| eventually be able to just target the browser from anything.
| For the life of me, I can't see a future where large, STEM-
| educated groups and agencies decide "Well yeah, I guess if we
| can use this cooked-in-a-weekend piece of $^&# then why would
| we ever use Python?"
|
| I think a lot of language enthusiasts see python projects
| entering into spaces where it wasn't previously viable and
| think that the same principle applies to their language,
| which misses something fundamental about why Python has so
| deeply entrenched itself into the STEM/ML world, and why it
| will NEVER be uprooted. When I see things like
| Brython/Pyscript/Pyodide, it's obvious to me that people
| would rather write Python for ~accomplishing the task they
| set out to~ than have to muck around with another language
| entirely. Python is a winner in so many spaces because of
| that element of taking the programmer from Point A to Point B
| the easiest way. It's a language designed for accomplishing
| tasks, for getting stuff done, for being understood at a
| glance. Javascript was made up by one guy, in a very short
| period of time, for a singular purpose that it didn't even do
| well when it was introduced and has stuck around due to sheer
| coincidence and convenience. All languages on a long enough
| timescale converge to a point of usefulness but if we're
| pitting Python against JS I just can't see the scales tipping
| enough to warrant choosing it for real work.
| culi wrote:
| Not JS, but I much prefer TS over Python. I've used all 3
| pretty extensively for scientific work as well as
| webscraping
|
| The thing is a lot of scientists are going to have to learn
| FE technologies eventually. The push to make scientific
| work more presentable and accessible means JS' place in
| academia is cemented for a long time.
|
| WebAssembly is still a long way off and given that even
| Rust WASM was found to usually do worse than JS, I highly
| doubt Python WASM will outperform it any time soon. Even
| once it does become worth it, tooling has a long ways to go
|
| > people would rather write Python for ~accomplishing the
| task they set out to~ than have to muck around with another
| language entirely.
|
| your argument seems to boil down to: people know Python so
| they wanna use Python. People can just as easily know
| JS/TS. If I'm a botanist and I really don't wanna invest
| too much of my time in learning languages I can choose
| between Python, the language with all the scientific
| libraries, and JavaScript, the language of the web. If I
| choose the former, I'll likely have to bother someone to
| help me present my work to the web anyways. If in the near
| future JS also reaches good support for scientific/ml
| libraries it seems like entering that ecosystem is an
| obvious advantage. I get to learn the web and access
| scientific libraries at the same time
|
| Also I don't really find Python all that legible. The
| language you're describing isn't Python nor JavaScript.
| It's something like Ruby. Modern javascript has some
| obvious advantages when it comes to syntactic sugar like
| arrow functions. It's also easier to teach because you
| don't need to install anything. Just open up your html file
| in any browser
| brrrrrm wrote:
| > If in the near future JS also reaches good support for
| scientific/ml libraries it seems like entering that
| ecosystem is an obvious advantage
|
| Fully agree with this sentiment. To that end, I've been
| contributing to Shumai (linked by someone else in the
| comments) to enable torch-like machine learning for Bun
| detrites wrote:
| > What scientist is going to want to write JS when they can
| choose Python?
|
| One who has a reason to?
|
| All languages have their strengths and weaknesses. Popular
| languages have a positive balance. JS is great for the web,
| and there's surely >0 applications in science that require
| web interoperability...
|
| The statement "mucking around with learning another
| language entirely", comes across as someone who hasn't
| experienced other languages to the point they see they
| often have more similarities than differences, become
| easier and easier to learn as a result, and are best used -
| at that point - like a box of tools, rather than the
| situation most programmers start with of using a
| screwdriver for everything because it's all they have.
|
| This is where more than a few scientists seem to have got
| stuck with Python, and possibly part of why the language
| itself has accelerated into becoming a bit of a mess -
| though they often do, anyway. (So much for that "just
| getting from A to B" thing, I hope it sticks around, but
| it's not looking good.)
|
| While many might not presently be in a position to, any
| scientist who _could_ choose to use something more readily
| suited to a particular use-case, such as JS, or C, or Perl
| /Ruby, or Elixir (particularly with regard to ML lately),
| may find themselves reaching higher heights than they could
| have when limited to only Python.
|
| As with anything, those with more options have an edge over
| those with fewer.
| sublinear wrote:
| I don't know what scientific hole this peg fits into, but
| it might make more sense to run something in the browser
| than on the backend (scalability).
|
| Instead of using a wasm runtime for python for that it
| might also make more sense performance-wise to at least
| write that part in js if not an even faster language
| compiled to wasm. Either way if it ends up on a webpage
| some js will be needed to at least glue things together.
|
| Also, from the perspective of just wanting to write some
| code and get what I want, I really don't see much of a
| difference between python and js.
|
| For the rest of us, it's kinda the other way around. We
| can't figure out why scientists prefer python over all the
| other many options. I'm assuming it's just a lot of cobbled
| together legacy code nobody wants to breathe on.
|
| > Furthermore, given that WebAssembly seems poised to
| (eventually) make strides in how browser-oriented
| applications are built
|
| Also, this isn't really true. The proposals and
| implementations out there suggest the goal is to use wasm
| for libraries and specialized optimizations. Nobody wants
| to wait for a massive binary to download. You can try to
| port legacy junk apps, but making it usable on the web (not
| a canvas) might turn out to be more work than it's worth in
| many cases.
| no_circuit wrote:
| Scientific performance critical code isn't written in
| Python, it is written in C/C++ which is used by Python.
| Python in ML usually merely describes the calculation not
| unlike React describes the DOM that should be displayed
| in the browser.
|
| JavaScript was never really known for admin or file
| manipulation (Perl replacement), so that was what
| probably established the dominant ecosystem for Python. I
| also don't think the runtime overhead is applicable due
| to native C/C++ part, and download time doesn't have to
| be bad since modules can be split just like in JavaScript
| ecosystem today. For an AI app, the model inference
| weights might be larger than the compiled WASM code
| itself. However, I'd agree with you that porting legacy
| apps might not be possible without something close to a
| rewrite.
|
| There is a reasonable chance that once WASM GC is
| implemented, then direct DOM access will be provided [1],
| which I believe could pretty much halt interest in new
| JavaScript development for web frameworks overnight. WASM
| is the reincarnation of the Java Applet, but better. And
| a more typed language like Go or Dart could become the
| most widely used programming language. Either compile it
| to WASM as plugin for something like the browser, compile
| to JavaScript for "legacy browsers", or to native code
| for a standalone app. There are probably a handful of
| developers already assuming this and trying to write a
| version of React running in WASM already.
|
| [1]
| https://github.com/WebAssembly/design/blob/main/Web.md#gc
| sheetjs wrote:
| JavaScript has a massive and unrivaled ecosystem outside of
| core data analysis. The main hurdle to adoption is
| ecosystem and community. A generation of applied
| mathematicians and data scientists were trained on Python.
| Python overcame older ecosystems like Matlab and Fortran
| for its ease of use for other general computing tasks
| (Matlab is a decent language for large array manipulation
| but soft tasks like string processing are kludgy compared
| to Python).
|
| In the same way that Python developers are interested in
| extending their ecosystem to other spaces, JavaScript
| developers are interested in growing into the data science
| space. But that doesn't happen unless there's a clear
| benefit for switching.
|
| What advantages do a native JS solution have over Python?
| Performance: There are arguably many more developers and
| companies focused on pure JS performance than python.
| Community: A JS solution opens up a much larger pool of
| talent to build innovative solutions. Cost: Running heavy
| computations client-side, in the web browser, reduces costs
| for service providers.
|
| PS: We're hiring for this and other related problems
| https://sheetjs.com/careers
| danielEM wrote:
| Why hiring US citizens only?
| KptMarchewa wrote:
| Pure JS or Python performance does not matter. Python is
| just a DSL to glue together C/C++/Fortran/Rust libraries
| in this context.
| de_keyboard wrote:
| Until it's not though. This is a pretty major
| architectural constraint on your code that you would not
| hit quite so early with a faster language.
| silisili wrote:
| Performance where, exactly? Most Python data munging I've
| seen just punts it all to C based libraries anyways. Are
| people doing things in pure python these days?
| sheetjs wrote:
| Under the hood, numpy and friends punt to native code.
| FFI / native module performance becomes a bottleneck, and
| Bun is correctly focusing in this area. Shumai [1] is a
| cool library for Bun that also punts to native code
|
| [1] https://github.com/facebookresearch/shumai
| throwawaymaths wrote:
| > What scientist is going to want to write JS when they can
| choose Python?
|
| A scientist that doesn't want to give whoever is
| responsible for deploying their software a massive headache
| and ops problems.
| zimbatm wrote:
| Relax man :)
|
| Let's say you want to a small notebook in the browser,
| JavaScript is nicer there, even with WebAssembly. Or the
| user is not a scientist, and already knows JS, and it lets
| them discover ML. It's not taking anything away from those
| Python projects.
| KyeRussell wrote:
| Given your extremely outsized reply I can tell this is
| something you feel passionately about or whatever, but the
| "JS was built in x days" line is a thought-terminating
| cheap shot. It doesn't acknowledge the vast amounts of work
| that have gone into subsequent ES versions. The JS that a
| typical remotely-modern-tech-stack developer is writing
| these days is not the JS that you're belligerently
| referring to.
|
| I've got honestly no idea how long it took to write the
| first 'version' of the Python interpreter or whatever. It's
| not as much a piece of tech lore that was later
| (mis)appropriated for Internet arguments. Even after
| acknowledging that JS being a browser-based language causes
| let's say 'less well-considered' language quirks to hang
| around for longer than we'd like, I'd never use that as
| such a central argument.
|
| To be clear: in my day job I predominantly write Python.
| It's a web project, which I have control over the
| architecture of, and it's for the most part oldschool
| server-side rendered Django views, in no small part because
| JavaScript scares me. I am FAR from a fanboy. Having
| recently spent a solid month writing TypeScript - which for
| contexts like this should be considered 'JavaScript' - it's
| (way too late) become clear to me that it's a language
| worthy of respect and consideration.
|
| If we want to get into the comparative qualities of JS you
| dislike, well, I still don't think I'd be interested in a
| language wars back and forth. However at least we'd be
| getting closer to a productive conversation. And, to be
| clear, I'm not jumping to take up arms arguing that
| JavaScript is as suitable for ML/scientific computing as
| Python is. Even if we pretend that e.g. pandas and numpy
| were available for JS, I'm still not confident that JS is
| up to the task, but I also don't feel confident arguing
| against it either.
|
| What I will say is that, coming back to writing Python
| after being deep in JS for just a little while, there are
| JS language features that I felt myself missing. Just like
| there are Python language features I felt myself missing in
| JS. My point is, again, that modern JS is in my eyes within
| the realm of respectable general purpose language,
| ESPECIALLY with TS.
| culi wrote:
| > What I will say is that, coming back to writing Python
| after being deep in JS for just a little while, there are
| JS language features that I felt myself missing. Just
| like there are Python language features I felt myself
| missing in JS
|
| I relate to this a lot. If I've been doing Python a lot,
| JS can feel clunky. If I've been doing JS/TS a lot,
| Python feels clunky. I think TS tips the scales here for
| me though
|
| The only language that I really feel is actually really
| elegant and readable and lives up to the "get stuff done"
| mantra in a way that goes beyond "this is what I know
| already" is Ruby
| yellowapple wrote:
| The irony of this comment, given that there is precisely
| nothing about Python itself as a language that makes it
| particularly suitable for "anything remotely scientific",
| is thick enough to spread on toast.
|
| I can see the validity of such an argument for languages
| like R or Matlab or Julia (EDIT: or Fortran), wherein the
| languages were designed with scientific use cases in mind.
| Python is not in that category; it's rather in the category
| of Perl (EDIT: and not Fortran): languages that happened to
| be useful to scientists by happenstance, and around which a
| library ecosystem developed in support of that usefulness.
| No fundamental reason why Javascript would somehow be
| ineligible if Python is eligible.
| adenozine wrote:
| I can see based on your perspective that you haven't
| collaborated with hundreds of STEM professionals,
| postdocs, or researchers.
|
| I can also see that your comment fails to address the
| meat of mine, despite being a reply to it.
|
| Python is extremely easy to get tasks done with, there's
| a minimal amount of ceremony and PLT background knowledge
| needed to program it. I love Perl, but explaining how $
| and @ work differently given the point of usage is
| annoying, and if I taught Perl all day every day, it'd be
| a continuous annoyance.
|
| I don't have the studies and data to back up my opinion,
| but a lifetime of work has taught me the certainty that
| Python is one of the greatest languages ever created,
| that quite literally ANYBODY who can type and read
| English can learn to become effective with it, and that
| it blows every competitor out of the water by a large
| margin with regards to getting from Point A to Point B as
| a novice programmer. As more of the world becomes
| programmers, that facet alone cements Python's continued
| success and its place in PLT history. It's the human part
| of the language, not the object system or type theory or
| compiler internals or any of the esoteric technical bits.
| Nobody can teach someone to program in anything other
| than Python quicker than I could teach them to program in
| Python.
|
| But anyhow, this is well below my time to spend in a
| discussion like this. I mean this in the nicest way
| possible: I've probably spent more time teaching and
| training people who weren't programmers to write good
| programs then you've spent programming throughout your
| life. People who work in the White House, DARPA, the FDA,
| DOT, IRS, you name it. I know I can't PROVE my position,
| but time will. Python will always win eventually.
| rykuno wrote:
| Honestly though, the original comment was just a plea for
| more competition to drive innovation it seems.
|
| Most of the data scientists I've worked with are
| programmer hobbyists as well. We've used
| Javascript/Python/Go/R. Maybe this will exist for people
| in that demographic, those who are data scientists that
| already are solid in programming.
|
| Regardless, more cool toys are good.
| hermitcrab wrote:
| >it's rather in the category of Perl or Fortran:
| languages that happened to be useful to scientists by
| happenstance
|
| From https://en.wikipedia.org/wiki/Fortran : "Fortran was
| originally developed by IBM in the 1950s for scientific
| and engineering applications"
| yellowapple wrote:
| Fair enough; edited, and thanks for the correction.
| rmorey wrote:
| What are some good resources to learn zig?
| Jarred wrote:
| - Ziglings is great - https://github.com/ratfactor/ziglings
|
| - zig.news has some good posts https://zig.news/
|
| - Zig's language docs:
| https://ziglang.org/documentation/master/
|
| - Zig's standard library code https://github.com/ziglang/zig/
___________________________________________________________________
(page generated 2023-01-18 23:00 UTC)