I've been working on X11 on jailbroken iOS - <AUTHOR> https://maxleiter.com/X11/ <comment><USER3> You just reminded me of jwz's portability efforts to keep XScreenSaver from being rewritten from scratch™ in the newest fad every time it comes around. He literally implemented X11 on top of Cocoa on top of UIKit on top of OpenGL on top of OpenGL ES just so that his hacks can still run. Though I wonder what will happen when Vulkan becomes the substrate API.

<comment><USER4> Good for him. Each to their own. That said, those hacks must be legendary for him to go to those lengths. Frankly I'm surprised xscreensaver is still around given all the various changes to window managers.

I've probably still got a few machines with a locally compiled version of xscreensaver lying around.

<comment><USER5> It's also remarkable that XScreensaver has one of the most stable DPMS implementations around.

Most screensavers and lockers lock-up the system while trying to switch the screen to low power mode on my PC but, XScreensaver works reliably. DisplayPort connection on nVidia cards is a pain point.

<comment><USER6> "(Display Power Management Signaling) enables power saving behaviour of monitors when the computer is not in use."

For those not familiar.

</comment></comment></comment></comment><comment><USER7> > _If you 're interested in using X11 now_

I'm interested!

Take a look on _AzPainter_ [0] — modern looking desktop app for painting, written in pure C with own toolkit built directly on top of X11.

Would be happy to see it ported to iOS.[1]

FTR, AzPainter already ported to Android, thanks to _Termux app_ dev team.[2]

[0] [https://github.com/symbian9/azpainter](https://github.com/symbian9/azpainter)

[1] [https://github.com/Symbian9/azpainter/issues/76](https://github.com/Symbian9/azpainter/issues/76)

[2] [https://github.com/Symbian9/azpainter/issues/6](https://github.com/Symbian9/azpainter/issues/6)

</comment><comment><USER8> Cool! I gave up on hacking on the iOS and macOS platforms because of how hostile Apple is towards it.

It's nice to see projects like this, I just hope that the rug doesn't get pulled out from under you after sinking time into it.

<comment><AUTHOR> checkra1n (current jailbreak for devices with A10 or older chips) is based on a BootROM exploit, so thankfully I can keep my iPad on newer iOS versions and remain jailbroken.

<comment><USER9> Do you know if checkra1n could eventually allow Linux based operating systems like Android or Debian to run on Apple mobile hardware?

<comment><USER10> Who's going to write the drivers?

<comment><USER9> Perhaps the same folks who previously had Android running on the iPhone 3G a decade ago:

[https://linuxoniphone.blogspot.com/2010/05/android-on- iphone...](https://linuxoniphone.blogspot.com/2010/05/android-on- iphone-3g.html)

<comment><USER11> The 3G had a commodity Samsung CPU core and 'off the shelf' third party subsidiary components, the drivers for which were available. Modern Apple custom in-house chips not so much.

</comment></comment></comment></comment></comment></comment><comment><USER4> Being ignorant of all things jailbreaking, is there a reason why X11 the display can't run on iOS? Surely an ios app can run a persistent background server, eg web? Or is it the swapping out/pausing that is the problem? Or is the answer to these simply a sharp edged and loud _NO_? We-say-so etc.

I fully get why Vnc/X11 as a screen sharing facility wouldn't work - <USER2> access. I also get why running a full devel environment would be pain for a "normal" developer to implement - again, no access.

This is all ironic because Apple market their iPad Pro as a professional device AND the cpu/ram is obviously plenty good enough (they themselves said so). The thing is more powerful than a Pi. And it meekly manages to compile quite a lot. My little Pi collection is now at 5 members and growing.

So, Apple, why can't I compile apps for ios on ipados? Hmmm? Wheels for the mind, think different etc

<comment><USER12> For some definition of "server", yes. [https://www.raywenderlich.com/5817-background-modes- tutorial...](https://www.raywenderlich.com/5817-background-modes-tutorial- getting-started):

 _"Your app is only allowed to keep running in the background in very specific cases. For example, these include playing audio, getting location updates or fetching the latest content from a server.

If your task does not fall into these categories, backgrounding may not be for you. You may even find yourself with an App Store rejection if you try to cheat the system by using background modes outside the realm of their purposes, so consider yourself warned!"_

If you read that, your 'server' either will only run for a finite time determined by the OS (in practice 3 minutes), or only run at highly granular times determined by the OS ( _"the system uses usage patterns to determine when to best fire off a background fetch. For example, if your user opens the app at 9 AM each morning, it's likely that a background fetch will occur sometime before that time."_ )

I think a X11 server that tracks updates for those three minutes of inactive time, and has a window manager that requests window updates where needed when the app becomes active could work, though.

(Disclaimer: these restrictions get relaxed over time on iOS. I may have missed some recent improvements)

<comment><USER13> Fortunately background apps are still not allowed or every app and his brother would find a reason to require it.

This kind of functionality would require an external server but then you may as well use VNC.

<comment><USER4> From what I can tell most "things that need persistent connections", including vnc or ssh, are not so persistent on ios.

</comment></comment></comment></comment><comment><USER14> This makes me happy. I have so much X11 code written over the past few decades, and I always fall back to X programming when I need to do something fast and in C. I've written a few simple iOS apps, but was frustrated with GStreamer support. Of course I have no idea what Cydia is... off to wikipedia.

<comment><USER15> For anyone else, Cydia is a dpkg based package manager for jailbroken iOS

</comment></comment><comment><USER16> Very cool, I wish jailbreak wasn't needed! Hopefully this shows Apple that people want to use their iPad as coding machines too...

<comment><USER17> Apple will eventually give you some kind of Xcode.

BTW, few years ago this guy made some Xcode remote before joining Apple Xcode team :) - [https://twitter.com/LouisDhauwe/status/1008071487721439233/v...](https://twitter.com/LouisDhauwe/status/1008071487721439233/video/1)

But that's only part of the problem. Still until Apple would give us the ability (similar to Android) running unsigned / not from App Store / no timebombs certs (similar to Android unknown sources), iOS is the most propriety platform and that's a shame.

<comment><USER18> I agree that Apple will eventually provide some sort of Xcode support. For now, Pythonista is a proof of concept that you can effectively write small Python programs on an iPad.

I plug my small iPad Pro into my USB-C interface large monitor and a few applications take advantage of dual screens to show different content.

For now, I find that I can code while traveling using a remote Linux server, Working Copy, Prompt ssh shell app, and Textastic for local editing. Not very convenient, but it works.

What is convenient on my iPad while traveling is writing. I use leanpub with markdown files stored in a github repo for each book, edit and do git stuff with Working Copy, and generate review PDFs on leanpub's web app. This works fine. On rare occurrences I use Microsoft Word on my iPad, works great, but I prefer markdown and leanpub.

</comment></comment></comment><comment><USER19> This is an absolutely batshit crazy idea. I love it.

</comment><comment><USER20> Add it to my list of "nice things we can't have inside the walled garden"

</comment><comment><USER21> I am confused, so is a X11 stack/server runs in an iOS device natively (not remotely) but you need a VNC client since a X11 client is not implemented yet?

<comment><USER22> You can do the same today, without a jailbreak using [https://ish.app/](https://ish.app/) which is an x86 emulator capable of running on the latest iOS / iPadOS versions. I do actually use it for work. Plus it works with standard x86 alpine Linux packages.

<comment><USER23> I guess technically _you can_ , but emulating x86 on arm sounds horrible. (Friendly reminder that nothing like JIT is allowed on iOS for third-party code.)

<comment><USER24> It's reasonable if you're doing some light editing.

</comment></comment></comment></comment><comment><USER25> An iPad is certainly a thin client...

More seriously though, while I am (or have been) persuaded that the restricted environment of iOS generally does make sense for the majority of people, I'd love to see official "blank" iDevices or an open developer mode available for them. Perhaps something similar to being able to install Linux on PlayStation's. They make very nice portable computing platforms for prototyping and development.

</comment><comment><USER26> Shame that newer devices can't have this

</comment><comment><USER27> Finally xeyes!

</comment><comment><USER28> Reminds me of Qmole.[0]

[0] [https://github.com/chriskmanx/qmole](https://github.com/chriskmanx/qmole)

</comment><comment><USER29> Interesting porting effort here for X11 on iOS. I'm not sure why I would use this but wouldn't it be beneficial for more iPhone jailbreak users to have Android dual-booting on their iDevice device?

If that were to happen, I would never need to buy a second phone like I would just use my single Macbook to triple-boot Windows, Mac and Ubuntu.

<comment><USER30> Well, for starters, you'd need to reverse engineer drivers for custom Apple hardware, some of which is hardened against that.

...And about 37 other extremely difficult things later, Apple would sue you.

<comment><USER24> Under what grounds?

<comment><USER31> Under the grounds of making them sad and you having way less money than they have.

</comment></comment></comment></comment><comment><USER32> What's with all the hype? This has been done over 10 years ago: [http://ingvar.blog.redpill-linpro.com/2009/11/17/running- nat...](http://ingvar.blog.redpill-linpro.com/2009/11/17/running-native-x- applications-locally-on-your-iphone/)

<comment><USER33> Will the approach in the article you linked work today?

</comment></comment><comment><USER34> Wouldn't porting Wayland be easier and more future proof than porting X11?

<comment><AUTHOR> Wayland is linux only, and will require significantly more work. Some work has been done on macOS, so maybe one day...

</comment></comment><comment><USER35> What about RDP would that be a possibility?

</comment><comment><USER36> need rooted ?

<comment><USER37> Yep, you'd have to be jailbroken / rooted to use Cydia.

<comment><USER38> Sorry, I must have been out of the loop. When was the jailbreak for iOS 13 published? (I'm also a complete stranger to jailbreaking—never done it before.)

<comment><USER39> Sometime in December, but Checkra1n is still in beta and only works up to the iPhone X since the bug was patched on the newer 2019 iPhones.

[https://canijailbreak.com/](https://canijailbreak.com/)

</comment></comment></comment></comment><comment><USER40> Bravo</comment>


Begginer in C. Critique my code and give ideas? - <AUTHOR> https://github.com/zeved/znote

<comment><AUTHOR> Hello HN. I'm trying to learn / relearn C (for real this time). Wrote this little tool for linux and I would like some feedback. Also, if you could give me some ideas for future small projects that would give me more experience in C... thanks!

<comment><USER2>
      int get_number(char buffer[])
      {
        long int i = 0;
        char *p;
        if(fgets(buffer, sizeof(buffer), stdin) != NULL)
      {

sizeof(buffer) will always be 4 (or 8 if you compile 64 bit) because sizeof(pointer to char) is 4 (or 8). It will NOT be the size of the buffer that you pass as an argument. To fix this problem you need to change the function to

      int get_number(char buffer[], int buffer_size)

Also the buffers that you pass to this function seem to be too small.

<comment><AUTHOR> thank you very much. i appreciate it!</comment></comment></comment>


Mona Lisa frown: Machine learning brings old paintings and photos to life - <AUTHOR> https://techcrunch.com/2019/05/22/mona-lisa-frown-machine-learning-brings-old-paintings-and-photos-to-life/ <comment><USER2> #smittened #deepfake #ai #ml #monaLisa

Finally.. ..2nd from the left explained so I can understand it why she is such a #warHorse..sorry Charleze, it's not going to happen.</comment>


Git Tips - <AUTHOR> http://mislav.uniqpath.com/2010/07/git-tips/

<comment><USER2> Another tip is adding all this to .gitconfig:

      [alias]
        b = branch
        co = checkout
        ci = commit
        st = status -sb
        diff = diff --word-diff
        l = log --graph --pretty=oneline --abbrev-commit --decorate

<comment><USER3> I've added my aliases to my bashrc instead.

      alias git="hub"
      alias ga="git add -A"
      alias gap="git add -Ap"
      alias gc="git commit -m"
      alias gs="git status -sb"
      alias gd="git difftool"
      alias gb="git branch"
      alias gco="git checkout"
      alias gm="git merge --no-ff"
      alias gp="git push"
      alias gpl="git pull"
      alias gf="git fetch"
      alias gcl="git clone"
      alias gr="git reset"
      alias gl="git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative"
      alias gre='git remote -v'

</comment></comment><comment><USER4> Some neat tricks, though I don't know how practical "Checkout a branch, rebase and merge to master" is - I find myself having to do manual mergetool stuff when I rebase off master enough that the one-liner would fail too often to be helpful.

I didn't know about --word-diff though - I'll be aliasing that to be the default for `git diff` for sure!

<comment><USER5> I envy your understanding—I'm struggling to figure out what that line is supposed to do. Is he switching to a different branch, squashing all of its commits into one, and then merging that branch back into master?

<comment><USER4> He is on master and probably just pulled/fetched the latest revisions. He has some work on a local feature branch.

* The first command switches over to that feature branch.

* The second command rebases off of master, which basically rewinds the changes on his branch and applies them to the latest version from master - think of this like getting latest and merging in your pending changes.

* The third command switches back to master.

* The fourth command merges the feature branch into master - this should be what is called a "fast-forward merge" and not require a separate merge commit since you rebased your branch.

The rebase is really used to make it a cleaner merge back into master (and a cleaner history in general), not to squash commits in this case (though you also would use rebase to squash, that's another topic).

What I pointed out is that (for me at least) the rebase from master is not usually "clean" - meaning there are merge conflicts that I have to resolve - so chaining together shell commands like this doesn't really help when the second command is going to need intervention from me before I can run the third.

Hope that helps (and I hope my analysis is right or I'll look silly!)

<comment><USER6> There's also an option to squash at merge time, which is commonly used going from a feature branch to an integration branch.</comment></comment></comment></comment>


What makes programming so difficult - and can we make it easier?  - <AUTHOR> http://kawagner.blogspot.com/2008/05/whats-makes-programming-so-difficult.html

<comment><USER2> Because the tasks that we ask the computer to do increase as our ability to handle more complex problems increases. I can ROCK almost any programming assignment and task of 20+ years ago given today's languages and hardware. But the problems are now bigger and more complex.

"Difficult" and "Easy" are moving targets.

</comment><comment><USER3> Programming will always be hard, but only because we're moving faster and faster. Your powerful, time-saving layer of abstraction becomes a library, tool, or platform, and you feel good for a while, but eventually productivity is measured against the new, higher baseline.

</comment><comment><USER4> Programming is just as hard in general as theorem proving. To understand why thats hard, read up on undecidability, to learn why they're the same intellectual act, read up on the curry howard isomorphism and the like <http://en.wikipedia.org/wiki/Curry-Howard_correspondence>

<comment><USER5> I think programming may be a bit harder because (at the end of the day) it becomes an engineering problem (one of efficient resource utilization). A program certainly has to be correct, but it also must run effectively on reasonably sized machines (less an issue these days for most problems), and implemented in a reasonable amount of time. The latter one is the killer that seems to never be accounted for in CS courses.

<comment><USER4> this is certainly true when you're considering the finest of algorithmic fu, (yay, that rhymes!) on the other hand, it worth mentioning that when you break out a computerize theorem prover to verify properties of say, a 15 line assembly bootloader, that winds up taking ~ 15k lines of code in the COQ theorem prover <http://coq.inria.fr/> (granted a lot of it was in libraries that were reusable)

as far as I can tell, proof engineering is the most technically challenging form of software engineering

</comment></comment></comment><comment><USER6> Programming would be easier if the language were uniquely suited to solving the problem (e.g. more built in solutions). In general, it is harder than it seems it should be because to create a language that is actually useful to a wide variety of applications, it needs to operate at a sufficiently low level so that you have the greatest equilibrium between ease of writing and function.

Can it be made easier? As a pmb said, not if the problems we are trying to solve are becoming more and more complex. But that's ok since only a limited number of people are actually interested enough (and dare I say capable) of programming. That might be a good thing though since the result is higher quality code/solutions.

</comment><comment><USER7> 1\. State. 2\. Functional languages.</comment>


Neural Ordinary Differential Equations - <AUTHOR> https://arxiv.org/abs/1806.07366 <comment><USER3> Senior author here, I'm happy to answer any questions.

We just released source code: [https://github.com/rtqichen/torchdiffeq](https://github.com/rtqichen/torchdiffeq) . This includes PyTorch implementations of adaptive ODE solvers that can be differentiated through automatically. So you can mix and match these ODE solvers with any other differentiable model component.

There's already been a bit of follow-up work, turning Continuous Normalizing Flows into a practical generative density model: [https://arxiv.org/abs/1810.01367](https://arxiv.org/abs/1810.01367)

And now we're mainly working on 1) Regularizing ODE nets to be faster to solve and 2) getting the time-series model to scale up and extend it to stochastic differential equations.

<comment><USER4> Could you place the work in context, and provide a simplified explanation for someone who understands math and ML, but is not familiar with the literature on normalizing flows and autoencoders? Thanks!

I tried reading, but the abstract and introductory section were a little too terse for me :-)

<comment><USER3> Sure thing. A few years ago, everyone switched their deep nets to "residual nets". Instead of building deep models like this:

      h1 = f1(x)
      h2 = f2(h1)
      h3 = f3(h2)
      h4 = f3(h3)
      y  = f5(h4)

They now build them like this:

      h1 = f1(x)  + x
      h2 = f2(h1) + h1
      h3 = f3(h2) + h2
      h4 = f4(h3) + h3
      y  = f5(h4) + h4

Where f1, f2, etc are neural net layers. The idea is that it's easier to model a small change to an almost-correct answer than to output the whole improved answer at once.

In the last couple of years a few different groups noticed that this looks like a primitive ODE solver (Euler's method) that solves the trajectory of a system by just taking small steps in the direction of the system dynamics and adding them up. They used this connection to propose things like better training methods.

We just took this idea to its logical extreme: What if we _define_ a deep net as a continuously evolving system? So instead of updating the hidden units layer by layer, we define their derivative with respect to depth instead. We call this an ODE net.

Now, we can use off-the-shelf adaptive ODE solvers to compute the final state of these dynamics, and call that the output of the neural network. This has drawbacks (it's slower to train) but lots of advantages too: We can loosen the numerical tolerance of the solver to make our nets faster at test time. We can also handle continuous-time models a lot more naturally. It turns out that there is also a simpler version of the change of variables formula (for density modeling) when you move to continuous time.

<comment><USER5> So one question about that. In

      h1 = f1(x)  + x
      h2 = f2(h1) + h1
      h3 = f3(h2) + h2
      h4 = f4(h3) + h3
      y  = f5(h4) + h4

the functions are all different. But to see it as "a primitive ODE solver", then the functions should be the same?

So if I understand correctly you have a different take on RNN's but not on deep residual nets in general?

<comment><USER6> > then the functions should be the same?

If we conceptually think that advancing from one neural net layer to the next one is the same as taking a time step with an ODE solver, then a bit more precise notation would be

        h1 = f(t=1,x)  + x
        h2 = f(t=2,h1) + h1
        h3 = f(t=3,h2) + h2
        h4 = f(t=4,h3) + h3
        y  = f(t=5,h4) + h4

Now you can say that the function f is always the same, but it still can give very different values for Δh when evaluated at different time points.

<comment><USER7> I do think it's misleading to compare the method to a general feed-forward network though, for two reasons.

First, to preserve the analogy between eq. 1 and 2, the thetas in equation two should have their own dynamics, which should be learned.

Second, even if Equation 1 doesn't allow it, in a general feed-forward network it's possible for the state to change dimension between layers. I don't see how that could happen with the continuous model.

Neat paper, but it'd be nice if they had tied the analogy more explicitly to RNNs in the introduction.

<comment><USER3> The comparison we make is to residual networks, which I think is valid. First, we do parameterize a theta that changes with time, using a hypernet. But this is equivalent to the way sampo wrote the equations above - you can just feed time as another input to the dynamics network to get dynamics that change with time.

Second, I agree that general feedforward nets allow dimension changes, but resnets don't. This model is a drop-in replacement for resnets, but not for any feedforward net. If we gave the wrong impression somewhere, please let us know.

We didn't make the analogy with RNNs, because I don't think it fits - <USER2> input-output RNNs have to take in part of the data with every time step, while here the data only appears at the input (depth 0) layer of the network.

<comment><USER8> Hasn't there been similar work to this in the past?

I don't see a "related work" section in your paper.

<comment><USER3> Section 7 is titled "Related Work".

<comment><USER8> Thanks,

Apologies for not looking harder

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Wow, I need to master ODEs/PDEs to keep up with Deep Learning now! Seems like one has to be a master of statistics, operations research, calculus and algorithms to push it forward!

Comparison to RNN was impressive! Any well-known real-world models for comparison to state of art?

<comment><USER3> The closest thing to a continuous-time RNN that exists are Neural Hawkes Processes [[https://arxiv.org/abs/1612.09328](https://arxiv.org/abs/1612.09328)]. They use a different model where observing the system necessarily changes its state, which is natural in some settings but doesn't fit in others. On the other hand, their model scales today and ours doesn't :)

</comment></comment><comment><USER10> Some reporting in MIT's newsletter on AI: [https://mailchi.mp/technologyreview/a-new-type-of-deep- neura...](https://mailchi.mp/technologyreview/a-new-type-of-deep-neural- network-that-has-no-layers)

</comment><comment><USER11> I remember something similar for CFD application but haven't seen much after that. It would be awesome if we can build a cheap and fast Navier Stokes solver with neural networks.

</comment><comment><USER12> Hi, I am very interesting about your models. When you do the back propagation, it seems that it still needs complex calculation. Although O(1) memory cost is an important contribution, do you think record some of the intermediate value will significantly boost the training?</comment>


Rate my startup: CarSpy - <AUTHOR> http://carspy.co

<comment><USER2> I agree with everything fugoki said, but here are some more observations:

* Can't middle-click results to open in new tab (Chrome / Windows XP...if I remember I'll check it out on my laptop (Linux) when I can).

* Dropdown for "Show 10/20.../All Entries" should look the same as the dropdown for make and model.

* The only clue that it was UK-only was the use of PS, not USD. I could imagine people not noticing that, and being confused about the results (it took my American postal code with no problem...)

* The dude in the logo has too much...jowls, or something. Maybe I'm crazy.

* I predict problems with owning carspy.co and not carspy.com.

* That's a slick slider you have to select the price/age/distance. Nice.

<comment><AUTHOR> Thanks for the comments. I was aware of most of the issues posted; its what I hoped was a minimum viable product.

The results links open with a js popup - would a regular link be better? just my concern is you'd navigate away from the search results if you left-clicked.

As for the .co - I can't afford a nice short .com right now, just need some funding to buy the .com!

</comment></comment><comment><USER3> I don't drive so it's f* all use to me :D, however…

• I can't select "Any" for the manufacturer so doing a simple search based on price isn't possible.

• Having to specify the model is similarly restrictive.

• Clicking through on the popular search links doesn't return a results page but instead pre-filled inputs? WTF?

• Search is chronically slow…

• Logo & tyre/spyglass @ bottom are inconsistent in style.

Good luck with it!

</comment><comment><AUTHOR> Looking for some feedback on my project of the last six months or so. Basically its used car metasearch, based in the UK.</comment>


Yahoo let's you log in with FB or Google now. - <AUTHOR> https://login.yahoo.com/config/login?.src=fpctx&.intl=us&.done=http%3A%2F%2Fwww.yahoo.com%2F

<comment><AUTHOR> I don't know if this is old news. But it seems kind of sad how far the mighty have fallen. To let your users sign in with your (old) competitors buttons. Ouch!!!

<comment><USER2> You've been able to do this for Flickr for quite some time and I believe all Yahoo login pages use the same template.</comment></comment>


A Siberian mammoth tusk gold rush - <AUTHOR> https://www.wired.co.uk/article/mammoth-tusk-hunters-russia-china <comment><USER2> Grim and disturbing for multiple reasons. It's deeply scary to me that the permafrost is melting like this and it also makes for uneasy reading to see that interesting archaeological finds are being sold off to make trinkets or simply left to deteriorate if they have no value. We're burning the world and then scrabbling around to sell the ashes.

</comment><comment><USER3> Related, more and better pics: [https://www.boredpanda.com/mammoth-tusk- hunting-russia/](https://www.boredpanda.com/mammoth-tusk-hunting-russia/)

<comment><USER4> And copyright infringed.

<comment><USER5> Wired have the cheek to ask you to turn off your ad blocker 'to fund their journalism' too!

</comment></comment></comment><comment><USER6> The article focuses on China, but people in America are buying some of this stuff, too. Some (mostly boutique) American guitar manufacturers offer mammoth ivory parts.

It's kind of depressing how many ethically challenging materials are used in musical instruments and how little buyers seem to care about it. Or rather, how little buyers seem to care about the ethical problems--exotic (and often endangered) materials are seen as highly desirable.

<comment><USER5> It's almost as if to accumulate the wealth to afford a musical instrument made of exotic ivory parts (with no effect on sound) requires a certain lack of ethics in the first place.

</comment></comment><comment><USER7> >Everything they left behind – mammoth skulls and bones – was consumed by the elements.

that's a shame.

</comment><comment><USER8> This is so disturbing. Soil that have been frozen for hundreds of thousands of years is just now thawing. Worrying.

<comment><USER9> I think you're off by an order of magnitude. Mammoths were around as recently as 4,000 years ago. For reference that's about when the Egyptian pyramids were being built.

<comment><USER10> His point was soil thawing, not the timespan of mammoths.

<comment><USER11> I think the GP meant "If the soil has been frozen for hundreds of thousands of years, how does it contain mammoths that lived < 10000 years ago".

Either the permafrost is younger than "hundreds of thousands of years" or the mammoths are older than 4000 years.

Mammoths lived from 5 million to 4000 years ago, so it could be either.

Edit: after some research it looks like both are right. Some permafrost in Yukon formed 700 000 years ago, some permafrost formed during the last ice age 10 000 years ago, some formed in the little ice age 400-150 years ago. That's not a complete list but you get the point.

<comment><USER7> > so it could be either. or both

<comment><USER11> You're right, it's both.

</comment></comment></comment></comment></comment></comment><comment><USER12> This reminds me of this tangentially related movie:

[https://en.wikipedia.org/wiki/Mammoth_(2009_film)](https://en.wikipedia.org/wiki/Mammoth_\(2009_film\))

</comment><comment><USER13> This has been going on for over a decade.

And it's not just China.

The ban on ivory is the driver.

<comment><USER14> The demand for ivory is the driver, the ban wouldn't be necessary if elephants weren't poached (and are being poached) to extinction.

<comment><USER13> Yes, totally.

But the driver for this is arguably the ban. From what I've heard, people weren't using much mammoth ivory before the ban. However, permafrost thawing due to climate change has certainly made it easier to dig up.

It is sad, though, that the availability of mammoth ivory complicates enforcement of the ivory ban. Ideally, it could reduce demand for elephant etc ivory.

I'm sure that C-14 dating would work, but it's still expensive.

<comment><USER15> > But the driver for this is arguably the ban.

I would argue that the driver is shortsighted humans who create demand for both ivory and mammoth tusks.

<comment><USER13> What's shortsighted about using mammoth tusks?

It's not like they contribute to climate change.

Or that the mammoths are alive to need them.

I mean, would you rather that they just rotted?

</comment></comment></comment></comment></comment><comment><USER10> I've seen these pics before and have noted that, given tusks are teeth and have a large amount of phosphorus in them, surely these buried tusks must have extracted then locked up an enormous amount of bio-available phosphorus which must(?) have seriously limited that plant nutrient.

Any thoughts from biologists?</comment>


Why Go is doomed to succeed - <AUTHOR> https://texlution.com/post/why-go-is-doomed-to-succeed/ <comment> vezzy-fnord Go is doomed to succeed because it extends the mental model of C with a concurrency model that finds a decent compromise between power and ease of use, makes the typing less prone to subversion, adds memory safety via GC, uses a structural subtyping system through interfaces that brings many OO-like benefits while still keeping to the C struct way of thinking, first-class functions, various syntactic rough edges cleaned up and so forth.

Because the Unix system programming world (and POSIX particularly) is very much built with the conventions and semantics of C in mind, most serious POSIX programming outside of C means you have to deal with painful FFIs, lousy wrappers, overly abstracted APIs that hide details like certain lower level flags and so forth. Some are better at this than others, of course (OCaml is one of the better ones)... but, nonetheless.

So it's unsurprising that many infrastructure developers are jumping to Go. There's just enough new things to incentivize a switch, but not _too_ much that it dissuades from it.

<comment><USER2> I'm a 90's C programmer and a Golang programmer now, and while there's some truth to this, it's reductive. A 2000s-era C programmer would not write socket code that worked the way net.Conn does. While C code gave us the "pipes and filters" abstraction of Unix, they are not an idiom in C code --- in fact, Golang's reader/writer interfaces feel more like a refinement of Java than a modernization of C.

Golang feels very much like an offspring of Java and Python to me.

<comment> vezzy-fnord Yes, Go has a heavy focus on interfaces and structural subtyping, as I said. It reflects the trend behind Pike's languages: C-like + some form of CSP + key abstraction.

But, even the net package has a noticeable Plan 9 legacy, like the use of dial/listen, as opposed to the clumsy Berkeley socket way. You might recall this was a central complaint of Pike's in his famous presentation "Systems Software Research is Irrelevant".

Obviously it's nowhere near as pure as ndb, but that's the reality of being in Unix.

<comment><USER2> I certainly can't deny the Plan9-ism.

</comment></comment></comment></comment><comment><USER3> It's very clear what Go is for. Go is for the kind of stuff Google runs on their servers. C++ is too complex, too unsafe, and too hard to maintain, and Python is too slow. (Remember that "slow" at that scale means "we have to add another acre of servers.")

Go is an OK language for server-side stuff. It's not perfect. The concurrency isn't as airtight as its proponents originally claimed. Reflection and type "interface{}" tend to be needed too often. Other than that, there are few killer problems with the language when doing server-side stuff.

The libraries for doing web server type stuff are available and well debugged. When you use a Go library that came from Google, you're probably using code that's executing a few million times a second on Google servers. (As I mentioned on here a few months back, I recently ported a medium-sized production Python program from Python 2 to Python 3. I found library bugs which would have been found long ago were the code heavily used.)

So yes, Go is doomed to succeed. That's not a bad thing.

As for Rust, while I like Rust personally, it may be too complex. The borrow checker concept is brilliant, and a huge advance in understanding how to avoid a big class of bugs. We'll see that again in future languages. The type and generic system, though, pick up where C++ left off, and seem to lead library developers to develop very complex interfaces.

Rust is for people who debate language semantics on Lambda the Ultimate and program in Haskell for fun. Go is for people who have a job to do.

<comment><USER4> That last paragraph is ridiculous. Name one feature in Rust that you think is too much complexity and I'll tell you where I need it _to get my job done_ in Servo.

Without generics and traits, for example, there would literally be no reason for Servo to exist, because it would be too slow. Performance is _not optional_. Safety is _not optional_. They are _my job_. If I opposed language features that are needed for competitive performance or safety on the grounds of complexity, _I would be failing to do my job._

I'm responsible for a lot of Rust's features. I have never posted on LTU, and I've never written more than 50 lines of Haskell. I find most of the Rust community's philosophical language debates tiring and pointless; languages to me are tools, not philosophies. The entire core team is largely with me here. I think you have a deep misunderstanding of the language design if you believe Rust has features "just because".

<comment><USER5> I don't read his/her criticism that way. It's that users of Rust tend to make over complex systems.

<comment><USER6> Can you provide an example of Rust users making overly-complex systems? Rust is a systems language, and systems themselves have intrinsic complexity that language designers must either choose to ignore or tackle. Scripting languages have the luxury of removing complexity by ignoring systems concerns so you don't have to care that your language is, say, copying strings around like a maniac behind your back. But somebody has to compete at the bottom of the stack, and while you can still seek ergonomic wins there's an enormous amount of essential complexity that can't be abstracted away.

</comment></comment></comment></comment><comment><USER7> Go succeeds because Google's behind it.

Go certainly doesn't succeed because of smug/boring articles like this one. The potshot at Erlang early on (also cf. slurs on Rust and Haskell in some of these comments) betrays the same old "we like it here in our cave" bias of Go boosters whenever confronted with its glaring warts.

Go is a great choice for certain workloads, is reasonably fun to code in, and has great doc support on the web. I suspect however it's popular also because it _isn 't_ FP and doesn't favor immutability. It plays well with the haters who refuse to understand how good GC/list fusion/stronger types/better abstraction can make code _easier_ to understand and _way_ faster.

But the bottom line is no Google, no Go. Just like no Sun, no Java. It's simply unbeatable to have a mega tech corp paying folks to write docs libs and patches. But it doesn't save it from being yet another turing tarpit.

<comment><USER8> Right, Google just needs to will something to succeed, and _poof_ , the world rallies around it. Like Dart, and Google Wave, and Google+, and Google Glass, and Google Answers, and Google Buzz. It doesn't matter if it's good or bad, because if it has Google's stamp on it, it's destined to be a wild success.

Certainly, having a big corporate sponsor doesn't hurt, but it's clearly neither a necessary nor a sufficient condition.

<comment><USER9> Yes, but Go solves a real problem for many people and isn't attempting to turn a profit. I wonder when it would be at the point where it could sustain relevance without further funding.

</comment></comment></comment><comment><USER10> > TL;DR Golang was explicitly engineered to thrive in projects built by large > groups of programmers with different skill levels, and there is no larger > such group than the open source community.

Very true.

This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but rather to create one that has a high enough abstraction to be productive but simple enough so that people coming from different backgrounds can acquaint themselves with it quickly.

In other words, it is a language for teams.

<comment><USER11> I would word it slightly differently--in Go you are free to express yourself in exactly one way: the idiomatic Go way. Anything else will be painful (a good clue is if you find yourself using reflection frequently).

<comment><USER2> That's true, but it's also (sometimes) liberating. In extremely flexible languages, you can find yourself burning lots of time finding the most "elegant" way to express simple concepts, like "how am I going to write this SQL column to this series of DIVs".

Not coincidentally, Golang sucks at this problem.

But there is something about writing in Golang that makes it easier to dive into meatier code. For instance: I've written programmable assemblers in Ruby and in Golang. With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler.

<comment><USER12> _With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler._

Same experience here. I am working on a neural net dependency parser and pretty much started C++ and Go implementations in parallel, because this was one of my first larger Go projects and I had my doubts about using Go for this.

In the meanwhile, the Go implementation is a complete and fast parser (the number crunching is done using OpenBLAS via gonum), which I now use for research. In C++ I am still tweaking the abstractions for the basic stuff (word embeddings, transition systems). Of course, I could make a simple, straightforward implementation in C++, but the language encourages you to finetune the abstractions and you have to the choice between template- heavy/light code (with its respective downsides).

I also found that Go encourages me more to break stuff up more in different packages. In C++, every separate library means new build machinery, some way to roll it out on systems, etc. In Go it's as simple as creating a new repository and adding imports.

</comment></comment></comment></comment><comment><USER13> I'm a fan of Go and have been using it for a [relatively] long time across various large and small systems.

I really like it.

To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic languages continues to awe me. This is particularly true for web systems that, on one end, deal with the object-relational mismatch and on the other transforms and outputs json or html.

Go's great, but it feels like we've forgotten some of the pain-driven lessons Hibernate and their ilk taught us.

<comment><USER14> Please tell me more about the pain-driven lessons Hibernate and their ilk taught us

<comment><USER13> We learned that you can't configure your way out of impedance mismatches. You can certainly make your life easier, but only at the cost of also making it harder.

You essentially need language-level support for dealing with data at your boundaries. Even with Java's strong reflection (Go's reflection is horrible) capabilities and generics (and C# extending that with lambdas and expression trees), there's still tremendous friction and boilerplate configuration and code.

Consider Dependency Injection, an ilk. In most (all?) dynamic languages, DI is a language concern, as opposed to a library concern. By having support for it within the language, the problems DI frameworks attempted to solve in Java (or C#) via messy configurations, legalese-like unit tests and quantities of code dedicated to nothing but the infrastructure of the codebase, simply vanishes. Now people are going to Go and discovering the awesomeness of interfaces.

</comment></comment></comment><comment><USER15> > _To understands why Go is the way it is you need to know why it came to > exist in the first place: "The goals of the Go project were to eliminate the > slowness and clumsiness of software development at Google, and thereby to > make the process more productive and scalable. The language was designed by > and for people who write—and read and debug and maintain—large software > systems. source"_

The problem with this idea is that, for the exact same goals, there could be a much better design for the language and much better implementation of various details.

You don't need to be Haskell or anything. Just Go + generics for example would result in a much cleaner language (no special casing for things like "make" for example), a vastly improved code library and data structures story, etc. This horse has of course been beaten to death (including by people working extensively with Go, so it's not like some "outsider's misconception" as some dismiss it).

If Go succeeds is because noone else with the same kind of visibility and resources tried to compete in this space (easy concurrency, static builds, fast compiles, static, fast-ish, decent batteries included etc).

You have e.g. Rust which is incomplete and too complex, Nim which is too niche, from very small vendor (a guy) and has some bizarro ideas, and that's pretty much it. That said, Swift might make a dent in this area when its Open Sourced if it has nice tooling.

<comment><USER4> How is Rust incomplete and too complex (especially "incomplete")?

Compiler-enforced-correct manual memory management may not be the right choice for every project, of course, but I think "too complex" is too strong of a way to say that. That implies there was a simpler way Rust could have achieved the same goals, and I've never seen anyone suggest one that works.

<comment><USER15> Well, it's a very common complaint (and I found it to be true when I tried my hand at Rust) that the lifetimes and general scope management can make your life hard -- and certainly harder than conventional GC languages. Rust, as a core language, has a lot more concepts to grok compared to Go or even Java.

As for incomplete, I mostly refered to the tooling and the available library ecosystem. Even Go lacks there, and Go is an order of magnitude better there than Rust. That said, despite the recent 1.0, the language is also heavily worked upon in several aspects (internals etc) and it doesn't seem that it's a "complete" offering that just happens to do incremental improvements, but a "we got an 1.0 out of the door, but we've got work to do to make it more mature".

<comment><USER4> > Well, it's a very common complaint (and I found it to be true when I tried > my hand at Rust) that the lifetimes and general scope management can make > your life hard -- and certainly harder than conventional GC languages.

Yes, there is more of a learning curve, but I think that's a problem with manual memory management in general. To me, that doesn't mean that the language is "too complex"; rather it means that the space Rust is playing in (and which those other languages are _not_ playing in) is complex.

> As for incomplete, I mostly refered to the tooling and the available library > ecosystem.

I've never found Rust lacking in tooling, with the notable exception of the lack of rustfmt (which is being worked on by Nick Cameron and others). I use native profilers and GDB with Rust almost every day, and Cargo is getting pretty mature. The library ecosystem isn't very mature yet, sure, but I wouldn't say that makes the language incomplete.

<comment><USER16> For many of us a complete language means the whole lot, e.g. IDEs, visual debuggers, a library for any use case, books.

This is most likely the why of the incomplete remark of the OP.

</comment></comment></comment></comment></comment><comment><USER15> > _Many critics I find though, fall into the second bucket. The answer to > those critics is always the same: "Go is just not for you". Some people see > this attitude as stubbornness from the community, aversion to improve which > will doom Go in the long run. They just don't realize that some people want > different things._

This trivializes all critique to "to each his own".

That some people "want different things" doesn't mean all things people want are equally valid.

</comment><comment><USER17> Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of- magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore- spot) or a simple daemon -- both because it doesn't require warmup and can be delivered as a single native binary -- but I just can't think of giving up the JVM's deep monitoring, low-overhead deep profiling[1], polyglotism[2], dynamic code loading and hot-swapping, and the awesome hacking power that comes with runtime bytecode manipulation[3] for long-running, important server applications.

[1]: Java Flight Recorder is the most powerful low-overhead profiler I've ever seen.

[2]: We use Java, Kotlin and Clojure all in the same project.

[3]: The ability to inject ad-hoc tracing code into your server and then take it out -- all while the server is running at full speed -- or to shadow binary dependencies so they don't clash, or to use (or write) a time-travelling debugger is like having magic powers. Bytecode manipulation is ultimate hackability.

<comment><USER18> It's not hard to find people switching from Java to Go (e.g. [http://www.infoworld.com/article/2608571/application- develop...](http://www.infoworld.com/article/2608571/application- development/article.html), which I found within 10 seconds of searching).

It's true that Go doesn't have a lot of those powerful JVM features that you listed, but as with any engineering trade-off there are lots of people who judge the benefits of Go to be worth the loss of those things.

<comment><USER17> Of course there are people making the switch, but the numbers are not nearly as substantial at as people switching over from scripting languages (even in nominal figures, let alone percentage) -- which perfectly makes sense.

You'll also note that since that article was published, all the advantages listed in in it have either found their way into Java (lambdas, fibers) or to other similar languages like Kotlin (multiple return values). Go has the undisputed upper hand when it comes to command-line apps (I really like it that I can use a language so similar to Java for stuff I never liked using Java for, and I was never fond of using scripting languages that require tedious dependency management for standalone programs), but is at a fundamental disadvantage when it comes to long-running important servers.

<comment><USER19> Go is particularly well suited to long-running critical server apps. It has fewer GC issues compared to Java and is also simpler language (making it harder to screw things up - Java generics can get very complex).

<comment><USER17> > It has fewer GC issues compared to Java

No, it has more GC issues. It's just that there aren't yet enough libraries and big applications to make that apparent. It hasn't been stressed enough just yet.

<comment><USER4> I think it's likely that Golang apps _won 't_ stress the GC as much as Java does, because of the simple fact that you can't realistically use j.u.c-style concurrent data structures, since you don't have generics. Where the JVM GC really shines is when you're using shared-memory concurrent data structures, which are really great things—however, without generics, programmers just won't use them in the first place.

(I'm not saying this is a negative for Java, BTW; making shared memory data structures both fast and idiomatic is really important if you care about performance of parallel code.)

<comment><USER17> Why do you think generics are more relevant for concurrent data structures?

<comment><USER4> Because "programs don't need more than one type of dictionary, so the language can just hard code one implementation in" is at least a defensible position in a single-threaded setting (although I don't agree with it), but it definitely isn't in a scalable parallel setting.

<comment><USER20> Yeah. Go. The concurrent language with a single, mutable, thread-unsafe dictionary implementation.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> Without a definition of "succeed", this cannot be argued against or agreed to. Like every other language, Go will be used by some people and not used by other people.

<comment><USER22> I believe "doomed to succeed" is a reference to language evolution and popularity; discussed by the Haskell community

[http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.schem...](http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.scheme/2009-04/msg00162.html)

</comment></comment><comment><USER23> Go's success has me confused. My team enjoys using Go, but to me it feels like i'm a prisoner. The designer's slavishly followed opinions are laser focused on reducing variation across go codebases. There's definitely less to learn than most languages. Unfortunately, sometimes the blessed way of doing things doesn't work well for your problem and not only are you left with a hammer to cut the wood, but making a saw is outlawed.

<comment><USER24> The article hits on this but doesn't bring up Google's high turnover rate.

Google is a resume tick box. Go over to AngelList and look at lists of startups. Take a drink every time you see 'worked at Google' listed as a qualification. You'll be destroyed in an hour or so.

Thus people get jobs at Google, put in a year or two, and go off for a higher paying and/or sexier job or a startup of their own.

Go is laser focused on simplicity, maintainable code bases, and uniformity to allow the next crop of Valley recruits to pick up where the last crop left off.

<comment><USER2> If this was true, and not a just-so story, then it should be easy to point to several well-known open source projects that started out in Golang and ended up in some other language, or several concepts that were prototyped in Golang and then ported over to some other language.

Like every programming language ever, there are surely many Golang users who've used it solely to add a keyword to their resume. That's not a very interesting observation, because the same thing is true of Rust, Scala, and even Haskell.

Further, that doesn't really address the question of why so many teams select Golang in the first place. A programmer might use Golang to get the keyword on their resume, but a team shipping a new product has no such incentive.

<comment><USER20> I think people who use Go in the first place are not those who think much about "can this be done in a better way?".

It's quite similar to the notion of "I'm a PHP developer and I don't understand why everyone says it is terribly designed! I learned to work with it and never tried anything else, so it can't be that bad!!!".

Not every developer cares about software development. There are plenty of people who chose this profession after they heard that a random developer can become the next Bill Gates by writing the right iOS app.

Having a language which doesn't require an inexperienced and non-interested developer to reflect on all the lessons learned in the last 40 years of software development and computer science fits the bill of this kind of person pretty well.

Sure, he/she is missing out on 4 decades of improvements to this profession, but who cares? Despite all the medical advances, there is still an economic niche for quacks selling "cosmic crystals" to cure your cancer.

There is nothing wrong with this. People don't pick a job in finance, because "they like to work with numbers" either.

We should just be aware of it.

<comment><USER25> Your argument seems to rely on go being the first language someone has learned. Very few people learn go as a first language. Most people I know in the Go community have 10+ years of professional development experience in a variety of the popular imperative languages and have used go for a couple years. I'm sure there are probably some people learning go as a first language by now, but I doubt it's a significant number.

So, "not knowing any better" is kind of ridiculous.

<comment><USER20> There are plenty of people out there which didn't manage or didn't need to advance beyond their first-year experience for the last ten years. "What did X do?" is a much better question than "How long did X do it?".

(For many jobs one year of experience is perfectly fine!)

I think people who can think critically and evaluate various options rarely join personality cults, which kind of explains Go's current community.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> "Go won't let you abstract yourself in the foot." :)

<comment><USER26> What a strange idea. The whole point of a programming language is to enable abstraction. I suppose assembler doesn't let you "abstract yourself in the foot" (whatever that means) either.

<comment><USER27> There is such a thing as too much abstraction. That's partly why Java has now that huge reputation of being a very enterprisey language.

<comment><USER28> That is actually due to a lack of rich abstraction mechanisms in Java.

</comment></comment></comment></comment><comment><USER29> _> TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community._

I think this premise could not be more wrong. The open source community is not a project team, and open source project teams are very likely much more homogenous and stable than teams working on commercial software.

Yes there may be non core contributors, but if contributions are not up to standard, they are simply rejected. If that means slower progress an open source project can live with that. A commercial project can not, because it has deadlines.

</comment><comment><USER30> It's an interesting language test, of how easy it is to understand an open source project.

Looking at github, the lines of code are usually easy to understand in C and java. What's difficult is how the parts of the project fit together (which is _never_ documented). Does Go help with that?

<comment><USER18> I think it can help with that in the sense that Go packages don't have complex boundaries and the type system is simple and self-contained. You don't have to trace an inheritance hierarchy to understand any given type, so a project of multiple packages is generally easy to understand just by reading each piece independently.

<comment><USER30> Inheritance can be a problem, but I was thinking more of the architecture, what calls what, who is in control, where are the various tasks done, what are the interactions... I'm not sure how a simpler type system would help with that e.g finding out which module does the task of interest, but I don't know Go.

[ Design patterns were supposed to help with this, with recognizable groups of classes. Sounds like a good idea, but I haven't found that, but maybe I don't know them well enough, or projects don't them well enough. ]

</comment></comment></comment><comment><USER31> Isn't the issue that people who generally like Go read and write articles like this? ;-) The same is said by PHP devs:)

<comment><USER32> PHP has (sadly) already succeeded.

<comment><USER33> yet I doubt that if doomed to success has anything to do with doomed to succeed forever

</comment></comment></comment><comment><USER34> Whether you like Go or not depends on whether you think of software development as engineering or as craft.

<comment><USER35> More like "... whether you've used any more modern languages than C" (such as ML and many other functional and research languages).

<comment><USER36> I have used SML, OCaml, Haskell, and many other languages, and I like Go, and use it for almost anything I do these days. So your statement is false. The only thing I did like more in functional languages was writing compilers (which ironically happens to be what I'm doing now in Go).

<comment><USER37> What kind of compiler are you writing? For which language and target?

<comment><USER36> For Go and sparc64, I did arm64 before.

<comment><USER37> You did the work to compile Go to arm64? Thanks for that then!

<comment><USER36> Yes I did, welcome!

</comment></comment></comment></comment></comment></comment></comment><comment><USER38> Compiled to native binary, garbage collected, no JVM and not object oriented is why I like it.

<comment><USER39> What's wrong with JVM?

<comment><USER40> Someone correct me if I'm wrong but I think not using the JVM makes deployments much simpler. At least that was one of the benefits a team at Amazon stated about switching to Go while I was there

<comment><USER41> In practice, it doesn't make much difference.

You install the JVM once and rarely upgrade it.

You build and distribute your Java apps as fat jars (meaning, all dependencies bundled.)

<comment><USER40> But what happens when some of the apps require different versions of the JVM?

<comment><USER42> As long as you're using the latest version then this shouldn't be a problem as the JVM is backwards compatible.

<comment><USER43> Except on those fun occasions when it isn't really. :\

</comment></comment></comment></comment></comment></comment></comment><comment><USER44> I highly recommend replacing any occurrence of, "Go is just not for you", with "Go is probably not the right tool for what you're trying to do."

The former can seem, snide or condescending, even when that is 100% not the intent.

I write both C++ and C# frequently. I love both languages. But I deal with people who use either language exclusively and continually gripe about the other. And the proper response is, "it's probably just not the right tool for the thing you're trying to do."

</comment><comment><USER45> > _accept that they won't change anything. The Go team has said time and again > that the language is done for the foreseeable future. You are too late to > the party. Some might cry about this, but this stability promise brings more > long term benefits than any language improvement could. Breaking changes, > even if for the better, are not always welcome_

The promise of stability from a large software corp puts in place a solid language foundation people can rely on when building apps in the language. Someone building a successful app using the language shouldn't be able to dictate future changes to the language based on their own needs only, ignoring smaller or less popular apps. Golang's language spec is a big help with this.

When you've tried working with a language whose backers cancel work on a spec for 10 years, then tailor the language's functionality for the one application they themselves are building, you appreciate the promise of stability. When the language's backers open up their AST to programmer addons via annotations, then later duplicate the functionality of the most popular addon, you appreciate the backing company's understanding that long term benefits come from nurturing the community.

When you see a backing company suddenly retrench all the staff working on a programming language, you appreciate that Google is using Golang internally and is unlikely to do the same. Although Golang was born of a Google internal need, let's hope the needs of their own systems won't dictate future changes _at the expense of_ the external community, and that they keep their stability promise.

</comment><comment><USER46> > Go won't let you abstract yourself in the foot.

What a brilliant sentence.

<comment><USER47> Abstraction if necessary but not necessarily abstraction.

</comment></comment><comment><USER48> "TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community."

This would almost be right, but Go has much poorer language interop than C due to the GC and non-C compatible ABI. This means unless we're going to a monoculture of GoAllTheThings (not likely), Go will never succeed C as being the basis of fundamental open source community projects.

For myself, I was and remain mildly interested in Go as my next move off of Python(2). And still believe Go is a better move than porting to Python3- which as an aside makes no sense technically, but the coercion/threats from the Python3istas are beyond reproach (as if the existing Python2 community is the problem), and set me solidly against it. Of this new generation of languages, Swift was always my ideal. Both in language and implementation. Now that it's going to the server I can't help but find the attraction of serverside Swift and getting in on the groundfloor of that ecosystem. While gaining skills in the language of iOS to be irresistible.

Count me in as one eager for Swift 2.0. I believe Swift is the language that is doomed to succeed. [http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

<comment><USER49> Swift has an interesting situation. Within 6 months of its beta release it was already being used to publish iOS & OSX apps.

With it also being open source, and ported to other platforms I can imagine other mobile operating systems also embracing the language in hopes to get more developer traction.

Not to mention that they have taken a little from every language, and server- side swift is a whole different beast.

This is going to be fun ;)

<comment><USER48> Yes sir. And I'm no "Apple guy". My first computer was a Commodore64, and I own no Mac. Never have. My only Apple products in my lifetime has been 1 iPod Nano, an AppleTV2 (only for jailbreaking/XBMC) and 1 company iPhone 5S (after 5 years and 4 Android phones, some personal, some company, all running CyanogenMod when possible).

I hate how languages like Go get lumped in with "Google", an association which to _me_ , is negative. For many, people fawn over Google, thinking a for- profit like Google does things in their best interests. When in reality it's temporarily mutually aligned interests.

I'm at the core if anything, a Mozilla guy. Not entirely because I'm not too diehard on the JSAllTheThings movement. I strongly lean towards native, even if my work consists mostly of Python2 backend for webapps. At least with native executing code it's _possible_ to be open source. You never know what's executing serverside. So I'm less of a fan of the so-called "open web" (an oxymoron) than most. And that's discounting the difference in end product that exists between native/web. I like my web to be it's original intended usecase- such as how HN is. Nothing too fancy, data sharing.

I think from a language/implementation standpoint that Swift hit it on the money. That's what I would have wanted out of a Python3. If that were Swift, I'd be a huge fan. Swift just nailed what I believe people are really looking for. Go is a little sketchy in ways. I don't hate it, don't actively work against it as I do Python3... well, can't say I work against it but I don't extoll its technical churn. But Go at least is trying to solve a real problem, and solves more problems than it creates. Even if I think it squares up against Java more than it does C or Python.

Unfortunately, Swift is associated with Apple which has its own zealots (and zealous haters). It's regretful that programming is now fashion, hype, trend. But I do think they have the best-of-breed language here for general purpose use.

My money and personal contributions to these new wave of languages will definitely be to work on server-side Swift solutions. The thought of a single- language solution with a single GOOD language from backend to front if you use iOS is pretty amazing and I'm really looking forward to that, and Swift backend / web frontend as well.

</comment></comment></comment><comment><USER50> Although Go was initially marketed as systems language it more often than not eats into Python's market share rather than C++ or Java's - at least in all places that I've seen it 'in the wild' (eg. saw that 1st hand at Google, read about that at Dropbox). Coming from professional Java or C++ development Go feels lacking but it feels like an incredible power-up when it replaces a piece of Python (or Perl, or Ruby, I guess...)

</comment><comment><USER51> I am not quite sure I agree with this article. It's like saying that C wont succeed because it lacks every single feature that is available in modern languages (I am not talking about C++ and above).

Go was designed to create low-level stuff with high-level language and it does not need features beyond that. It has enough features to satisfy some extreme low level tasks. If you want high-level programs then write them in your favourite scripting language. I prefer coffescript due to its expressiveness but I realise that t is not everyone's cup of tee.

However, for low-level programming and where I know static compilation and performance is a key, I will go with go. Why? Because it will take me 10 times longer to do it in C. And although I like C, I will not kill myself to use it unless I am really have to.

P.S. my company has done some amazing stuff with go, docker, fleet and coreos in a very short time. I have no doubt it would have taken us much more time if we had decided to use something else.

</comment><comment><USER52> Is there any "best practice" Go, especially in terms of architecturing apps? I come from a long php background, and spent the past 3 weeks learning and prototyping a Go project. Looking at my code, I definitely have "open source stage fright". Any links/advice/books appreciated.

<comment><USER25> Gofmt your code. Run errcheck, golint, and go vet, and make sure they don't complain. Run go test -race and make sure it doesn't complain.

The best Go code uses built-in types and small interfaces in its APIs. Use interface{} as a last resort, and then only if your function can really take anything. Don't overuse channels. Sometimes a mutex is more appropriate, and that's ok. Rarely use reflect. Don't panic except during package init. Never ignore errors. Don't try to make your Go code conform to the way other languages work. Magic is bad, don't try to make your code magical.

The go community is quite nice in general (there are bad apples in any group). Show off your code, it's the only way to learn, and chances are you'll get some good review comments at least.

</comment></comment><comment><USER53> I'm curious about two things.

(1) where does Rust fit in this?

(2) and if Go is lacking in the concurrency department and loses to Erlang in latency. Why don't people use Erlang/Elixir for servers and Python/etc for client side?

<comment><USER54> > Why don't people use Erlang/Elixir

Because Erlang is _different_. It's not just the syntax, even though that throws many people uncomfortable with much that's not a direct descendant of C syntax; it's the whole programming model which requires a real shift in perspective that simply isn't easy.

It's worth it once you start to "get it", but that can take a bit.

I do think Elixir gives the Erlang VM a better shot at the big time, because it lessens the syntax obstacle for many people.

<comment><USER55> > _Because Erlang is different._

I'd say that fails to capture the full scope of the statement.

From where I stand, Erlang is not just a language - it's an extremely robust, highly opinionated event loop with its very own DSL.

<comment><USER37> > an extremely robust, highly opinionated event loop with its very own DSL

It's very reductive. Erlang is a distributed platform with a functional programming language, lightweight processes communicating through distributed asynchronous shared-nothing message passing, preemptive scheduler, etc.

</comment></comment></comment></comment><comment><USER56> This is a very light article with not too much information. Go already succeeded simply because Google uses it. This means all of the problems they need to solve in Go has decent support (net/http etc.) and you can just use in your own projects, and this also means that the out of the box performance is decent. These are good enough reasons to use Go. If you are talking about language features I don't think that Go is that amazing. Supporting CSP is a big win though.

</comment><comment><USER57> this:

      > Go won't let you abstract yourself in the foot.

aside from being amusing -- I like this, but can anyone confirm its true in practice with Go?

<comment><USER25> The lack of generics (and operator overloading and type hierarchies) makes it hard to write grandiose frameworks and all but impossible to write DSLs. I consider this a good thing. You're definitely pushed in the direction of writing straightforward, no frills code that uses boring types with little magic.

</comment></comment><comment><USER58> A language success is largely determined by marketing. Go will succeed because a lot of brilliant people are using it and it's not bad. That's exactly why node.js is where it is now, and PHP was cool back in the days.

That said, I'll just leave this here: [http://yager.io/programming/go.html](http://yager.io/programming/go.html)

</comment><comment><USER59> God, this is a beautiful turn of phrase: "Go won't let you abstract yourself in the foot."

</comment><comment><USER60> I don't quite buy that a pretty low level language reduces developer fright. In my mind Go is a replacement for C more than the next Python. In that respect it is still intimidating for developers who have never done or done very little low level programming.

<comment><USER61> I friend of mine who has dabbled in C for years is still pretty scared of it. He loves Go. He's gotten Go into production where he works. I think there are a lot of people like him.

</comment></comment><comment><USER62> Plan9's failure payed the karma points for go's success. Duh.

</comment><comment><USER63> Go is simply the follow on to Limbo. It is the product of many years of experience supporting the construction of large systems. Most of its roots are from Bell Labs.

</comment><comment><USER64> This article seems to suggest that Go was designed as a language for large teams. Firstly it was designed as an research project and secondly I don't think it does work for large teams.

The simple type system and lack of genetics makes code verbose. The dependency system seems to require everyone is on the bleeding edge, correct me if I'm wrong. The channel based concurrency is very elegant but appears to be too coarse grained for high performance programs that would otherwise use it.

That said I like the languages simplicity and do think it has it's uses in the world. Just not large team, large project development.

<comment><USER27> Go is not about research in the sense of inventing new things. The holy designers of Go (Ken Thompson, Rob Pike, Russ Cox) have clearly stated that Go only borrows from other languages (C, SmallTalk...). The goal is not to reinvent the wheel in a new, confusing language, but rather to put together parts that have been thoroughly tested. They make sense together and the result is a boring language that is made to be used.

</comment></comment><comment><USER65> To put it roughly, Go was made to appeal to Java developers as a better Java replacement. In contrast Rust was created to appeal to C++ developers as a better C++ replacement.

</comment><comment><USER66> Maybe these _programming in the large_ languages don't necessarily have to be fantastic for programming in the large, and in the long term. But they have to be great for this at least in the short term. So imagine that such a language shows itself to be good for making medium-scale applications in the first year (assuming that large-scale applications take longer to become "large-scale"). The code is uniform, people can easily get up to speed with whatever section they are working on, there are no _big_ surprises - great. This language gets adopted in more projects because of the initial rite of passage, and some luck and marketing (hype and random factors seems to be given for new technology, in the short term). So more projects spring up following the same model. These also work great, and by now we have a handful of new, discovered concepts associated with learning and using the language. The language, ecosystem and implementations are still lean and easy to comprehend. And so some years pass.

Now this language is actually used for _large_ applications. It's still all gravy, the code bases are still uniform and easy to understand. People can easily be trained. More projects adopt this language, or even use it to build things from scratch. It gets applied to more domains. Years pass, and things that were unobservable in the beginning start to rear its head. They weren't _non-existing_ , but they were so minuscule in this large landscape (remember - big adoption of this language) that it was unobservable from the bigger picture. Now what was a problem for a few developers seems to be a problem for many people. For a while, they solve this pain point by educating about certain patterns to look out for and solve. This works for a while, but after a while more pain points become apparent. And like for the initial pain point, it is just not a pain point for a small group of ignorable developers, but indeed a systemic one. There seems to be something wrong. We can't simply solve this pain point with education and applying patterns - we need _abstractions_. There is some murmur about this - the principal point about this language was to avoid over-abstracting things. We need to practice constraint. This works for a while, but after some time the concerned voices of the people advocating this kind of restraint gets drowned out. These limitations are just _too much_ for people to deal with. So people start suggesting and inventing so-called _abstractions_. And pain points are relieved. After a while you have a whole cottage industry of these abstractions. And people's day to day life with this language and its associated code bases are happier and more productive. On the other hand, there is more to learn now, and things aren't straightforward any more. You can't simply look up a library and have flat, easy to read code. You also need to learn the associated _abstractions_. You also notice that the technologies associated with these abstractions are getting kind of _big_. They are starting to take on a life of their own. And it seems like they don't really _fit_. Some of them feel kind of shoe-horned in, as if there was no general slot for them already installed, it just had to be jammed in there.

Now, is this language good for large-scale development? The language is still easy to learn. Somehow. There was a bunch of additions up through the years to ease some pain points. Not all of jive as well with each other, or with the original language. But with some elbow grease, it is perfectly serviceable. Not to mention all the associated technology that cropped up to assist the language in its ascent - _that_ is the hard part. So the language is not _really_ easy to learn any more, with the associated things. But people know it, there are code bases to maintain and it has proven that it isn't _useless_.

Is the language good for large-scale development? Doesn't matter. It already won and is here to stay.

</comment><comment><USER67> Destined to succeed might make better english.

<comment><USER68> Aw, c'mon - where's your sense of imagination! No one would click on an article with that title (except Go fans). "Doomed to succeed" surprises the reader and entices them to see what it could possibly mean. It's a fantastic title!</comment></comment>


Graph of NP-Complete Problems - <AUTHOR> http://page.mi.fu-berlin.de/aneumann/npc.html <comment><USER2> I was wondering what the arrows actually mean. Turns out A->B means that A can be reduced to B (using a "polynomial-time many-one reduction"). So if we assume that B is NP-complete, A is too.

So it all boils down to showing that Circuit Satisfiability is NP-complete. I guess this graph shows the order in which the reductions were actually done for the first time. When I was at college, we reduced everthing to 3-SAT and directly proved that 3-SAT is NP-complete, I think.

<comment><USER3> _> Turns out A->B means that A can be reduced to B (using a "polynomial-time many-one reduction"). So if we assume that B is NP-complete, A is too._

It's the other way around. For a given problem to be NP-complete requires that every problem in the NP superset be reducible to it in polynomial time. So in the A->B case, if we know A to be NP-complete, we have just proved every problem in NP is also reducible to B in polynomial time, by ways of any-NP- problem->A->B, ergo B is NP-complete.

<comment><USER4> A well known quote (in the right circles):

"Real men reduce from 3SAT" -- Christos Papadimitriou [<http://www.cs.berkeley.edu/~christos/>]

</comment></comment></comment><comment><USER5> For those wondering:

 _dot - makes ``hierarchical'' or layered drawings of directed graphs. The layout algorithm aims edges in the same direction (top to bottom, or left to right) and then attempts to avoid edge crossings and reduce edge length._

 _neato and fdp - make ``spring model'' layouts. neato uses the Kamada-Kawai algorithm, which is equivalent to statistical multi-dimensional scaling. fdp implements the Fruchterman-Reingold heuristic including a multigrid solver that handles larger graphs and clustered undirected graphs._

source: <http://www.graphviz.org/>

</comment><comment><USER6> I'm not entirely sure I see the value of this. Note that it doesn't tell us much about the state of the world, but rather more about the historical order in which these problems were inducted into the NP-completeness club. And by the time enough data points have been added to the picture to cover a meaningful fraction of the NP-complete problems that have been studied, will it even be possible to make sense of the humongous graph?

There are meaningful distinctions within NP-complete problems, such as whether they are easy to approximate. Perhaps if the graph incorporated that information, I can see this going somewhere..

<comment><USER7> It is incredibly useful for us kids just now learning about algorithms and trying to see if the problem described in the text book is reducible to a known NPC problem.</comment></comment>


Are You Agile Enough for Agile Management? - <AUTHOR> https://www.wsj.com/articles/are-you-agile-enough-for-agile-management-11565607600?mod=rsswn <comment><USER2> Agile means ability to be extremely short term oriented. I think this is extremely important, but also detrimental at the same time.</comment>


Zig 0.3.0 Released - <AUTHOR> https://ziglang.org/download/0.3.0/release-notes.html <comment><USER2> If Andy's watching, congrats!

Two minor things:

> zig init-lib and init-exe

Wouldn't these be better off as "zig init lib" and "zig init exe"? I.e. do what git did when it switched from stuff like "git-annex" to "git annex": switch from compound command names to subcommands. Easier mentally to follow and remember.

There's also this:

> all control flow occurs exclusively via keywords.

This will probably never happen cause C looms too large in Zig's world, but I wish "*" and especially the super non-intuitive "&" go the way of the dodo and some short keywords replace them. Perhaps "ptr" and "deref"? This is technically just bikeshedding, but look at Rust threads: besides the obvious #1 difficulty of the borrow checker and ownership, the #2 complaint is that the syntax is weird due to sigils. "Modern" programming languages don't use many sigils, if any: Javascript, Python, Java, C#, etc.

It's not fair since those languages are GCed, but most people will be familiar with them, not with C, these days.

I know that it's doubly unfair since Zig's target is C, so it's expected that new Zig developers know C, but you want to get new developers wherever you can get them, in my opinion :)

<comment><USER3> The sigil thing is definitively a bikeshed. For one thing besides Python I don't don't know why you consider that JS, Java or C# don't use many sigils, these languages just happen not to have C-style pointers so they don't need that particular bit of syntax.

More generally using C-style syntax means that C and C++ coders will be at home, while people from other languages will have to familiarize themselves with the concept anyway, sigil or not.

Beyond that, I don't think I've seen any serious study on the acceptable level of sigils to maximize productivity and readability in source code, as far as I can tell it's really just a matter of opinion. Personally I'd take C syntax over Python every day of the month, and I've written quite a bit of Python. My only sigil-related problem with C is that '->' should really just be '.' IMO.

<comment><USER4> There's was a talk at StrangeLoop a few years back about a language syntax being designed based on user feedback from its ongoing usability studies. I'm on my phone now, but I'll try to find and post the link later when I'm at my computer if someone else doesn't find it first.

</comment></comment></comment><comment><USER5> So happy to see this language develop rapidly. I want Zig for simple, rapid and fun microcontroller development. There's just no satisfying options right now.

I played around with it some months ago. It was an adventure so to speak. Even discovered bugs in LLVM itself. Andy was very responsive to bug requests, so I got a demo working pretty quickly.

I'm hoping to do another pass soon, perhaps contribute a bit to the compiler.

The demo is here: [https://github.com/skyfex/zig-nrf- demo](https://github.com/skyfex/zig-nrf-demo)

Probably doesn't work anymore.. but that's the way it goes with a developing language :) That's part of the fun

<comment><USER6> I've had fun writing some stuff in CircuitPython [0] (a fork of MicroPython mostly geared towards Adafruit microcontroller boards). At the moment it is geared more towards educational and hobbyist uses, but there is a quite a bit you can do with it.

[0] [https://github.com/adafruit/circuitpython](https://github.com/adafruit/circuitpython)

</comment></comment><comment><USER7> Just a small suggestion, but:

> _Zig intends to be so practical that people find themselves using it even if > they dislike it._

feels awfully condescending to my ears personally, in an _I 'm-smarter-and- know-better-than-you_ kind of way, even if you didn't intend it like that.

Just my unsolicited $0.02, but I'd recommend a more objective and non-loaded description something along the lines of "Zig's primary motivation is practicality, and therefore avoids issues with C such as <x, y, z>".

<comment><USER8> To throw in dissenting opinion: I feel like that gets the point across to C programmers like me.

</comment></comment><comment><USER9> Can anyone with more experience/understanding of Zig give an elevator pitch about why and when I would use Zig? I love the concept of a low level language that's not C, but the home page doesn't paint a clear picture to me about what its strengths are and in what situations it really shines, and what trade-offs it makes to get there.

<comment><USER10> The short of it is C without the warts plus a few small quality of life improvements.

The long of it: The competition right now in this space as I see it is: C, Rust, C++. Even C++ doesn't fully fit because you have to turn off language features like exceptions to have the guarantees you need for systems programming. So in turn.

C hasn't really changed in 40 years so all it's warts are still intact and has specific pain points that will never be addressed.

C++ conversely has added every language feature plus the kitchen sink over the past 30 years. People say: "Just don't use the features you don't want", but that is unrealistic when you have to interoperate with third party libraries etc. If you have to drop a large portion of the C++ ecosystem to use the subset of the language you like then you've lost a major benefit of choosing C++ in the first place.

Rust, while being more thoughtful about it than C++, has provided a large set of features to work with. It is a much bigger language than C. It's also taken a very opinionated stance on safety with the borrow checker which causes a large learning curve and a lot of mental overhead.

Finally Zig is an attempt to be more safe than C where it can without being as overbearing as Rust. Add just the necessary features that a huge boost to quality of life while not flooding the programmers mental model of the language. I think of it as kind of a C+.

<comment><USER11> Rust's borrow checker does not have a lot of mental overhead while working once you are moderately proficient.

It imposes design constraints that in the end work out for the better. This is why Rust users are so fanatical about it.

<comment><USER10> > It imposes design constraints that in the end work out for the better.

I feel the jury is still out on this. It does impose design constraints that remove a certain subclass of errors, whether this correlates to actually causing better designed programs in the sense of readability, maintainability, etc. I'm unsure. I understand the desire for this to be true and I feel that some of the fanaticism around the language is the belief that this is true. Developers like to have the 'one true way' to solve problems. Go's popularity I feel is in part because of this as well but achieved it by having a bare bones language with less options instead of a restrictive compiler. If you take the 'restrictive compiler' argument to its logical conclusion for a program that accepts input x and produces output y there would only be one valid way to code this program. This would be good in the sense that presumably the compiler has proven that your program works and is correct. On the other hand though I have no inclination to believe that this program would be the most understandable, modifiable way to get from x -> y.

<comment><USER9> Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve, which can be confusing and counterproductive when choosing a language _because of_ the classes of errors it aims to solve (often a big motivator in both designing and choosing a language; see Swift and Go).

<comment><USER12> >Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve

What are some of those?

<comment><USER13> The big one is memory leaks. People also assume "race conditions" instead of "data races."

<comment><USER12> Thanks for the info. I need to look up the latter point, the difference between the two. Saw it mentioned in an article or book about Go too.

Looked it up, found these links, for anyone interested:

[https://blog.regehr.org/archives/490](https://blog.regehr.org/archives/490)

[https://stackoverflow.com/questions/11276259/are-data- races-...](https://stackoverflow.com/questions/11276259/are-data-races-and- race-condition-actually-the-same-thing-in-context-of-conc)

<comment><USER13> Any time! And yeah, those links are excellent.

<comment><USER12> Cool, good to know :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> the amount of development described in detail the release notes is simply amazing. thanks for your work and i'm excited to see zig continue to progress.

</comment><comment><USER15> How does generic code work in the absence of destructors? Is there an analogue of psuedo-destructors?

</comment><comment><USER16> If anyone is interested, I'm using Zig full-time. I switched from C# to C++ for game development but I had immense difficulty accepting the language, so when I heard of Zig I gave it a go and I've been very happy with it.

This is a serious project that I'm working on. The 'engine' uses the Vulkan graphics API, cache efficient design, scales to the number of cores, game logic is multithreaded, AVX is used, and so on.

I only mention this to hopefully get people interested in Zig. I'm not ready to share screenshots yet and I'm certainly not going to be advertising my game here.

<comment><USER17> I've followed Zig's progress with some enthusiasm, but would have considered it too immature for a serious project at this point. In that vein, a few questions about your experience:

1) What's your workflow like in terms of tooling? Coming from C# and C++ people are typically used to great IDE support, debugging and profiling tools, etc. Zig doesn't have any of that. How do you work around it and do you find the experience reasonably productive?

2) How do you deal with the language still rapidly evolving? Do you run the latest nightlies or freeze a particular compiler version and update periodically?

3) What are the most important things Zig gets you over the traditional gamedev approach of using a restricted subset of C++ (in some cases literally just C with function/operator overloading for basic math and a few other convenience features)?

<comment><USER16> 1) When I programmed in C++ I was using Vim and the YouCompleteMe plugin for IDE-like features. Now I use Vim + CTags. For CTags I use the following which uses the Zig standard library to parse Zig code: [https://github.com/isaachier/ztags](https://github.com/isaachier/ztags). In the future there will be support for the Language Server Protocol.

2) I git pull every few days to run on the latest compiler. The bugs that I've hit have been minor inconveniences, nothing serious. I think Andrew would agree with you though that Zig is probably too immature for a serious project at this point. The transition to the self-hosted compiler has yet to take place, that compiler is in its infancy.

3) I'm afraid that my verbal inability will never do Zig justice. The built in slices and optionals are really nice. Pointers are non-null by default (but can be undefined). Stack traces on crashes. Much better casting in my opinion (once I got used to it). Error handling that's similar to Herb's C++ deterministic exception proposal. No headers. Not having to decide between fast compile times and comfortable printing. Defer statements instead of destructors or nothing work really well in my opinion. Built in testing (maybe not something you use much in gamedev). +% means add with overflow, + means overflow is undefined. Everything feels nicer, that's as good as I can put it.

edit: You can Ctrl+F "pub fn" to browse all public functions. Great when browsing Github. It's easy to grep for the definition of anything. Overflow and other undefined behavior is detected in debug mode, this saves me so much time. Guaranteed inline is nice. No more make/cmake and manually listing which files to compile.

<comment><USER17> Thank you for the detailed responses. One, possibly silly, followup question, since you mentioned using AVX. If I understand correctly, Zig deliberately avoids macros, metaprogramming and doesn't have operator overloading. Given those limitations, how do you deal with vector math over different SIMD widths without insane verbosity? I feel like I'd be tempted to write a simple code generator before starting on something like that.

<comment><USER16> Zig has extensive metaprogramming support.

For SIMD I'm using ispc which is a shader-like language/compiler from Intel. You write your code from the point of view of a single SIMD lane and the compiler takes care of the rest. Intel kind of screwed the project over with their stupid naming and terrible website but it's a very cool project. I take the resulting object file and link it with the rest of the project. This is very different from trusting a compiler to vectorize your code, with a shading language you know it's going to vectorize. What's absolutely brilliant is when you start to use divergent control flow and see how well it handles it.

[https://pharr.org/matt/blog/2018/04/18/ispc- origins.html](https://pharr.org/matt/blog/2018/04/18/ispc-origins.html)

</comment></comment></comment></comment></comment><comment><USER18> Heh, if you ever came into a place that had used Zig and we're now transitioning to a different language, your job would be to-- literally--"remove all Zig".

<comment><AUTHOR> Too late. All your codebase are belong to us.

<comment><USER18> I would call all the programs "gentlemen" and inform them they were on their way to destruction</comment></comment></comment>